Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

netflix.github.io

Post reply on HN
Print view View original

31–40 of 91 posts

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

#31

Post by passive »

ikeboy wrote: post #6

So is this basically selenium in javascript with some neat features?

I think this is more of a complement to Selenium, where you can use Selenium to drive the browser to test the UI, with Polly providing recorded back-end responses. I need to look into it more, but this might address a need we have to make it easy (and quick) for our front-end developers to run our test suite locally during development, without having to spin up anything in the backend or rely on flaky non-Production environments.

EDIT: I am aware there are many other tools that can address this, we just haven't had the time yet to implement them. :)

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

#32

Post by ikeboy »

tootie wrote: post #28
ikeboy wrote: post #21

Earlier quoted context omitted.

What's the core distinction between this/wiremock vs selenium?

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

The example is form filling though:

    await fillIn('email', 'polly@netflix.com');
    await fillIn('password', '@pollyjs');
This is exactly like selenium code I've written to login. I struggle to see the difference in purpose.

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

#33

Post by reymus »

Mandatum wrote: post #25
bicubic wrote: 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 won't work for WebSockets, really websites that use WebSockets require some interaction to generate the transmitted message which is often dependent on the servers response. Private websites, or websites that require a login are hard - but it can be done. Would suggest HTTrack.

But it's not impossible to have some tool that records all of those interactions to reproduce later. A smart enough tool could record everything since you open the site until you click save. It would not reproduce the functionality that is backend dependent, but iy sure can replicate the dom, etc. Am I missing something?

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

#34

Post by cottsak »

tootie wrote: post #28
ikeboy wrote: post #21

Earlier quoted context omitted.

What's the core distinction between this/wiremock vs selenium?

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 completely obsolete.

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

#35

Post by error54 »

staticassertion wrote: post #13
burger_moon wrote: post #10

I would love to hear from people involved in projects like this, what kind of work/ how much, was done to get it ready for and approved to be open sourced by the company. Especially at large corps like Netflix I'm sure there's a lot of hoops to jump through.

Netflix seems to also have a really strong culture around this though, so I wouldn't be surprised if it's a lot less hoopy than you'd imagine.

Not to shamelessly plug but if you're in the Bay Area on June 28, we're giving a talk that's a bit about performance, a bit about Netflix engineering culture: https://jstalks2018.splashthat.com/.

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

#36

Post by xelfer »

swyx wrote: post #27
youdontknowtho wrote: post #17

Earlier quoted context omitted.

Yeah. I was going to bring up the library for .net that provides policy based retries.

i went to the slackbot that has a cute parrot logo. we at CodingBlocks love our Polly.

I thought of Amazon Polly.. converts text to lifelike speech.

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

#37

Post by dekz »

ikeboy wrote: post #32
tootie wrote: post #28

Earlier quoted context omitted.

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

The example is form filling though: await fillIn('email', 'polly@netflix.com'); await fillIn('password', '@pollyjs'); This is exactly like selenium code I've written to login. I struggle to see the difference in purpose.

> /* start: pseudo test code */

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

#38

Post by tootie »

ikeboy wrote: post #32
tootie wrote: post #28

Earlier quoted context omitted.

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

The example is form filling though: await fillIn('email', 'polly@netflix.com'); await fillIn('password', '@pollyjs'); This is exactly like selenium code I've written to login. I struggle to see the difference in purpose.

That's part of mocha or whatever. Polly is the server part.

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

#39

Post by tootie »

cottsak wrote: post #34
tootie wrote: 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…

It's not always easy. Especially not if your API is stateful.
Post reply on HN