many thanks for you this fantastic library, I used it in several projects. It is the core of my new testing philosophy that prefers integrative testing.
One problem I always have though:
The headers as part of the key inside the request always differ and consume time to figure out.
In the most cases I end up excluding almost all headers at the end, one by one. Specifically on CI environments a list of complete new headers additionally comes up, so it needs one more config with some dev ops guy.
So how about introducing a list of NOT ignored headers (e.g. considerOnlyHeaders) , basically the negation of the ignoreHeaders list. All other headers will be ignored?
By having that you would reduce the last complexity by setting up a new project with that and make it more transparent what is the actual comparison key for each tape. This can be an extra config not touching all the previous users with this feature.
Hi @ijpiantanida,
many thanks for you this fantastic library, I used it in several projects. It is the core of my new testing philosophy that prefers integrative testing.
One problem I always have though:
The headers as part of the key inside the request always differ and consume time to figure out. In the most cases I end up excluding almost all headers at the end, one by one. Specifically on CI environments a list of complete new headers additionally comes up, so it needs one more config with some dev ops guy.
So how about introducing a list of NOT ignored headers (e.g. considerOnlyHeaders) , basically the negation of the ignoreHeaders list. All other headers will be ignored?
By having that you would reduce the last complexity by setting up a new project with that and make it more transparent what is the actual comparison key for each tape. This can be an extra config not touching all the previous users with this feature.
So what do you think, would that make sense?