Live data from Hacker News

Polly.js – Record, replay, and stub HTTP interactions

netflix.github.io

51–60 of 91 posts

Re: Polly.js – Record, replay, and stub HTTP interactions

#52
post #46

Looks well done (it uses unicode art, so it must be amazing) but I have a fundamental distrust/dislike of record/replay frameworks...just seems like you're papering over an inherently bad testing approach. E.g. sure, when replays work, they're great, but: a) you have to do a manual recording to create them the first time (which means manually setting up test data in production that is just-right for your test case) b…

[deleted]

Re: Polly.js – Record, replay, and stub HTTP interactions

#53
post #46

Looks well done (it uses unicode art, so it must be amazing) but I have a fundamental distrust/dislike of record/replay frameworks...just seems like you're papering over an inherently bad testing approach. E.g. sure, when replays work, they're great, but: a) you have to do a manual recording to create them the first time (which means manually setting up test data in production that is just-right for your test case) b…

> you have to do a manual recording to create them the first time (which means manually setting up test data in production that is just-right for your test case)

Your test invokes the the recorder. There isn't anything manual outside of writing & running your test.

> you have to manually re-record when they fail

Again, nothing manual. It would require running your test again with Polly in record mode if you want to "refresh" the recording with a newer set of responses.

> In both cases, you've accepted that you can't easily setup specific, isolated test data in your upstream system, and are really just doing "slightly faster manual testing".

This is by no means a replacement to E2E testing. It is a form of acceptance/integration testing where you're testing your application against a point in time that you verified all systems were talking correctly with your application. E2E tests are much slower, difficult to debug, and intended to capture those breakages in contracts.

It's a tool for your toolbox, reach for it when needed. We plan to release a tutorial/talk to should clear up any misconceptions. There are also other applications for Polly such as building features offline or giving a demo using faker to easily hide any confidential data.

Re: Polly.js – Record, replay, and stub HTTP interactions

#54
So VCR gem for javascript. Great! Personally I stopped using VCR gem a while back as it blocks edge cases. However for larger projects where things can get unwieldily this makes a lot of sense. Local test suites should never hit external APIs so it's much better to have mocks/stubs than to have no tests at all.

However on smaller projects I've found that just clicking through to make sure things work and then letting my error reporting system catch bugs to be much more effective :)

It's a hard line to walk and I surely haven't perfected it. I'll give it a shot on a future project!

Re: Polly.js – Record, replay, and stub HTTP interactions

#55
post #49
post #46

Looks well done (it uses unicode art, so it must be amazing) but I have a fundamental distrust/dislike of record/replay frameworks...just seems like you're papering over an inherently bad testing approach. E.g. sure, when replays work, they're great, but: a) you have to do a manual recording to create them the first time (which means manually setting up test data in production that is just-right for your test case) b…

How is this distinct from other http stubbing libraries?

Polly records as well as exposes a stubbing API. So it's quite different from what I've seen of the others.

Re: Polly.js – Record, replay, and stub HTTP interactions

#56
post #20

Related to that, is there anything that allows to completely save the state of a modern website with all of the fetch requests and websocket related stuff it fired off? I just want an ability to save and reopen exactly what I'm looking at. There are some cool websites which will eventually go down and I want to preserve an interactive snapshot of them.

This is part of a webtop I built called qKast (https://qkast.com) In fact the chrome extension https://chrome.google.com/webstore/detail/qkast/eliofljjghgd... let's you mix and match live components of webpages and make "living" snapshots, further then that though - they're not i-Framed so you can use an assortments of widgets to modify the contents and look of the components as well as broadcast the whole webtop live.

Re: Polly.js – Record, replay, and stub HTTP interactions

#57
post #42
post #12

Earlier quoted context omitted.

https://netflix.github.io/pollyjs/#/README Why Polly? Keeping fixtures and factories in parity with your APIs can be a time consuming process. Polly alleviates this by recording and maintaining actual server responses without foregoing flexibility. * Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests. * Use Polly's client-side server to modify or…

Not sure that tells me how it's different from replay or the other half dozen npm modules that do the same thing. It'd be nice for them to contrast their tool with existing ecosystem options considering some of them are pretty well established.

Can you share which libraries you know that achieve the same thing? I'm happy to go through and respond to the differences.

Re: Polly.js – Record, replay, and stub HTTP interactions

#58
post #49

Earlier quoted context omitted.

How is this distinct from other http stubbing libraries?

Polly records as well as exposes a stubbing API. So it's quite different from what I've seen of the others.

Ahh. Well, there’s quite a history of recording as well as stubbing: see ruby’s VCR.

Re: Polly.js – Record, replay, and stub HTTP interactions

#59
post #34
post #28

Earlier quoted context omitted.

Selenium is for behavior testing. Simulating clicks and form filling. This is for mocking http endpoints.

I still don't get why we do this [mocking http endpoints]. Sure this makes the problem of mocking the server less painful. Well done. But I'd take completely integrated tests over these any day. Sure they're slower but that's more or less irrelevant with feature toggling, staged roll-out and continuous production monitoring. It's totally possible to completely avoid mocking http endpoints thus making these tools comp…

See my comment above. This is not a replacement for E2E testing.

Re: Polly.js – Record, replay, and stub HTTP interactions

#60
post #42

Earlier quoted context omitted.

Not sure that tells me how it's different from replay or the other half dozen npm modules that do the same thing. It'd be nice for them to contrast their tool with existing ecosystem options considering some of them are pretty well established.

Can you share which libraries you know that achieve the same thing? I'm happy to go through and respond to the differences.

I only have experience with replay, but an npm search turns up:

replay, replayer, http-record, talkback, sepia, mitm-record, fetch-vcr, tape-nock, jest-playback, eight-track, axios-vcr, replayer, node-vcr, mocha-vcr, mockyeah, yakbak, nine-track, dkastner-replay, node-nock

At which point I stopped looking...recording http requests isn't exactly new territory.

Post reply on HN