
Introducing yakbak: Record and playback HTTP interactions in Node.js - johns
http://code.flickr.net/2016/04/25/introducing-yakbak-record-and-playback-http-interactions-in-nodejs/
======
dv0rak
Super lame that its wasn't a clone of this beauty from my childhood:
[http://media-cache-
ec0.pinimg.com/736x/71/5c/62/715c62a2fc9d...](http://media-cache-
ec0.pinimg.com/736x/71/5c/62/715c62a2fc9debb9255a2ac3f1a4f89f.jpg)

------
askmike
> [mocking HTTP..] We’re still completely implementation-dependent. If we want
> to pass a new query string parameter to our service, for example, we’ll also
> need to add it to the test so that nock will match the request.

Yes, if you change your API you need to update your tests anyway.

\---

I haven't played with it or looked at the code, but the only advantage I see
is speed of writing tests: hit run, store the "tape" and you don't have to
write any specific mocks (which makes it very good imo). Except when you want
to test edge cases (specific error messages from the server, time outs during
response, errors on the network level, etc).

I wouldn't talk about the speed since it should be the same as a traditional
mock.

> Look, no implementation details!

Isn't the HTTP module considered stable? So your API is more likely going to
change then node's HTTP implementation (when was the last time this changed?).
In which case you need to record new tapes anyway.

~~~
royjacobs
> Yes, if you change your API you need to update your tests anyway.

And if you mock your responses you can easily edit it to update it to the
latest version of the API.

This "tape" approach leaves you with a bunch of opaque blobs that may or may
not be easy to recreate or update, since they require a server to be in a
specific state to create them in the first place.

~~~
Osiris
I don't like recording requests/responses because of this. In these cases, I
prefer to manually write the test without running the code because I want to
make sure the test matches what I _expect_ my code to do, not record what it
_actually_ does. I caught an error yesterday in which a recorded response was
used as an expectation, so the test passed. The bug was only exposed when I
wrote a new test and manually created the request/response objects based on
the docs. The test failed and I found the bug (a field was being transposed
during transform of the response).

------
dmuth
How is this different from Nock's ability to record HTTP streams and put them
into tests for later "playback"?

[https://www.ctl.io/developers/blog/post/http-apis-test-
code](https://www.ctl.io/developers/blog/post/http-apis-test-code)

~~~
adyus
It doesn't seem to be (very) different. The blog post mentions Ruby's VCR
library but not the node-equivalent [https://github.com/carbonfive/nock-
vcr](https://github.com/carbonfive/nock-vcr) or
[https://github.com/poetic/nock-vcr-recorder](https://github.com/poetic/nock-
vcr-recorder).

It's simply a new approach to a solved problem, it seems.

------
yeukhon
I tried to implement similar thing so I kudo people for completing it. What is
actually very useful IMO is being to use this in vulnerability testing. All
the automated pentesting tools I know of can only touch the very basic
vulnerability in a blackbox way. Imagine you can capture some sample traffic
coming into your web server. Now most requests go through very similar routes.
Rarely you will find a user hitting page X from page Y especially if page Y is
some API people rarely would use or protected. You can also use the sample
traffic and learn if there are any potential malicious payload. It's like
putting up a real firewall I guess.

------
mikgan
There are a few of these kicking around now. In a similar space is the "Pact"
group of libraries. Give them a look in too:

[https://github.com/realestate-com-au/pact](https://github.com/realestate-com-
au/pact) [https://github.com/DiUS/pact-consumer-js-
dsl](https://github.com/DiUS/pact-consumer-js-dsl)

------
kangman
What is the difference between using this or the gor project or twitter's
diffy project?

~~~
LeonidBugaev
`yakbak` is about service virtualization, to help you remove 3-rd party
dependencies for your tests, and replace them with recorded responses.

`diffy` is a reverse proxy which multiplex requests to multiple endpoints,
compare differences and detect regressions between responses.

`gor` is about interception your production traffic (it is not a proxy, more
like a network analyzer), continuously, and replaying it on demand to your
test environments (you can modify and filter this traffic using various ways).

Hope it helps.

PS. I'm Gor author.

