ijpiantanida / talkback

A simple HTTP proxy that records and playbacks requests
MIT License
283 stars 41 forks source link

Preserving the order of requests for each tests #86

Open zakir8 opened 9 months ago

zakir8 commented 9 months ago

I have used VCR gem in ruby before and it makes it seemless by creating one tape for each test which can be pointed to after the recording is done. It also goes down the requests in the order it receives during recording. It might be more opinionated, but it makes for a more repeatable integration test.

I am using selenium-webdriver with talkback to record the requests and playback in DISABLED mode to repeat application behavior. The issue is that if the same requests are being made with different responses, only the first one recorded is played back. In my scenario, I have an empty body response in the first response, and then a non-empty response after an action is taken on the webpage. I can certainly deleted the earlier tape with the empty response, but that wouldn't reflect realistic integration testing which talkback intends to solve.

An example I would like to use is adding to cart functionality. I would like to take the user through adding a product to cart by adding something from the page. At the first the cart is empty which means the response was empty, and then the user adds something to the cart which means the response is filled with a product object. This wouldn't precisely reflect the order of actions by the user in talkback.

It's possible I maybe overlooking something here. I look forward to your response.

denislutz commented 9 months ago

Hi, I dont fully understand your use case, but it smells to me like a situation where a custom header would make sence, that make your request fully unique. I had situations like this... This is what I did couple of times.

Look into allowHeaders config property (very important). ( Btw GPT can greatly read the whole doc and help you with config. )

Define your custom header, only for your dev environment like... allowHeaders: [ 'custom-tape-id-header', 'content-type', ]

In the code at runtime create a header that represents your current request state context in the best way (can be something like current userId and more) like

const customHeaderValue = ${yourStateAttribute1}_${yourStateAttribute1}_${yourStateAttribute1};

Use your header in the request

  const customHeaders =
    EnvS.isTest() || EnvS.isDev()
      ? { 'custom-tape-id-header': customHeaderValue }
      : {};

Now record your tapes, which will know much more about the context...

Generally it should not be exaggerated though, cause you start creating code only for your dev needs, but it can help....