Feature Request: Add a RecordMode.ALWAYS option about talkback HOT 4 OPEN

I see how this mode can be useful, but I'm doubtful about simply creating multiple tapes that match the same request, since that could easily slip through and lead to unwanted and hard to debug confusion.

I'm not sure what a good solution could be though. Even telling that 2 tapes are for the same request is not straightforward since the matching can be dynamic through some of the options.
If you want, you can create a PR to add the ALWAYS mode, and I'll try to think of and add a good way of alerting users that more than one taped matched a request.

from talkback.

I'm using talkback to test a frontend SPA in isolation from API backend with selenium tests and I'm facing the same situation. SPA sends the same http request twice during a test and the actual response from API is different in both cases. Having something like RecordMode.Always could theoretically help.
I've started looking into talkback code to figure out how much changes are needed to support RecordMode.Always.
I guess if multiple tapes are matching the request, I need to return them in chronological order (based on meta.createdAt). Do you see any potential issue with this approach?

from talkback.

The problem I see with this approach is:
Requests 1 and 2 come, so talkback returns those 2 tapes in the original order. Now comes a 3rd request, because let's say, you're running another test that goes through the same flow.
How does talkback know that the cycle started again?
What if one test makes 2 requests and another one makes 3?
What if one tests is broken and it skips a request? How do you make sure that only that test breaks without affecting the rest of the suite?

These are all problems related to the fact that talkback isn't aware of a "test context" and that all tests share the same collection of tapes, and that you're trying to mock something stateful with something stateless.

The solution that other libraries take for this, is to make each test have its own set of tapes, and make the mocking server stateful.
This comes at the cost of having to repeat tapes and difficulties with parallelism, so I'm not sure it's a tradeoff worth taking.

from talkback.

Either way "ALWAYS" doesn't clearly communicate what makes it different from NEW vs OVERWRITE (-both are currently much less ambiguous in comparison).

Perhaps what we mean is a "multiple" or "loop"-variation to each of NEW/OVERWRITE, which could use a logic similar to this:

• NEW: unless tape "${name}" or "${name}_0" exists, record new request as "${name}_0"
• OVERWRITE: if tape "${name}" or "${name}_*" exists, delete them and record new request as "${name}_0"
• NEW_LOOP: like NEW but in addition to tape_0, also record consecutive request using _1, _2, _{n} suffix.
• OVERWRITE_LOOP: like OVERWRITE but also record consecutive request using _1, _2, _{n} suffix.
• DISABLE: if ${name} exist, play it back. if ${name_*} exist, play it/them back in order, when finished, start at _0 again.

(note: involving non-suffixed names, in order to keep them backward compatible with existing recordings.)

from talkback.