Alternate URL (no Javascript required): https://github.com/Netflix/pollyjs
Polly.js – Record, replay, and stub HTTP interactions
51–60 of 91 posts
Re: Polly.js – Record, replay, and stub HTTP interactions
#52Looks 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…
Re: Polly.js – Record, replay, and stub HTTP interactions
#53Looks 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…
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
#54However 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
#55Looks 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?
Re: Polly.js – Record, replay, and stub HTTP interactions
#56Related 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.
Re: Polly.js – Record, replay, and stub HTTP interactions
#57Earlier 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.
Re: Polly.js – Record, replay, and stub HTTP interactions
#58Re: Polly.js – Record, replay, and stub HTTP interactions
#59Earlier 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…
Re: Polly.js – Record, replay, and stub HTTP interactions
#60Earlier 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.
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.