4 ms·

It does not include SSE or WebSockets. With regards to updating existing records, unfortunately we don't currently have good tooling & support for this, so you

It does not include SSE or WebSockets. With regards to updating existing records, unfortunately we don't currently have good tooling & support for this, so you may need to record new sets of sessions as your application changes. I would suggest starting off with testing a few core flows.

Klaster_1 4y ago
Thanks for clarifying. The value proposition of automatic request/response recording brings something genuinely new to the area, but without a WS support, not all projects could benefit completely. This reminds me of the test suite for one of my projects where E2E tests only covered relatively simple scenarios because of subpar WS mocking support, leaving more important, complex interactions to manual (can't run in CI) or fully integrated (expensive to author and run often) testing. The situation changed only after we wrote a custom WS mocking layer over the HTTP mocking the framework provides, yielding a dramatic increase in coverage. Out of dozens of developers I interviewed, only a few solved this issue to some degree. Clearly, mainstream testing frameworks provide insufficient support for the use case.
- gary_chambers 4y ago
  I agree that WS replay could be very powerful, but I'm not sure it's straightforward. Once you get out of the realm of request/response and you are dealing with subscriptions, connection multiplexing, or frankly any other sort of pushed data that is triggered by whatever is on the other end, knowing how and when to play that back against new sessions is very hard. It seems very application specific on face value. But I agree that it would enable replay for a lot of very interesting, complex projects. I've worked on some FX trading UIs that have been challenging to test without standing up a lot of backend services.

4 ms·

It does not include SSE or WebSockets. With regards to updating existing records, unfortunately we don't currently have good tooling & support for this, so you

by Gabriel_h 4y ago

Klaster_1 4y ago
Thanks for clarifying. The value proposition of automatic request/response recording brings something genuinely new to the area, but without a WS support, not all projects could benefit completely. This reminds me of the test suite for one of my projects where E2E tests only covered relatively simple scenarios because of subpar WS mocking support, leaving more important, complex interactions to manual (can't run in CI) or fully integrated (expensive to author and run often) testing. The situation changed only after we wrote a custom WS mocking layer over the HTTP mocking the framework provides, yielding a dramatic increase in coverage. Out of dozens of developers I interviewed, only a few solved this issue to some degree. Clearly, mainstream testing frameworks provide insufficient support for the use case.
- gary_chambers 4y ago
  I agree that WS replay could be very powerful, but I'm not sure it's straightforward. Once you get out of the realm of request/response and you are dealing with subscriptions, connection multiplexing, or frankly any other sort of pushed data that is triggered by whatever is on the other end, knowing how and when to play that back against new sessions is very hard. It seems very application specific on face value. But I agree that it would enable replay for a lot of very interesting, complex projects. I've worked on some FX trading UIs that have been challenging to test without standing up a lot of backend services.