Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserving the order of requests for each tests #86

Open
zakir8 opened this issue Nov 22, 2023 · 1 comment
Open

Preserving the order of requests for each tests #86

zakir8 opened this issue Nov 22, 2023 · 1 comment

Comments

@zakir8
Copy link

zakir8 commented Nov 22, 2023

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants