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
incompatible behaviour introduced with v13.3.2 #2500
incompatible behaviour introduced with v13.3.2 #2500
Comments
can we close in favor of #2501? Maybe you and @andreas-roessler could work on a PR? |
hi, as far as I can see #2501 has nothing todo with the problem I reported. The solution of the compatibility issue I reported is to revert 8aab603 which changed the order of interceptors after execution and with that the precedence. The new behaviour is not a side effect of the commit merged by @mikicho. It is the intended behaviour which is unfortunately incompatible and lead to plenty of problems in our testing zoo. |
My 2 cents. I tried to solve two problems:
@andreas-roessler It appears that the example in the ticket is a simplified version of your current setup. Can you generate nocks only when needed instead of always saving the full scope? |
hey @mikicho, We often use nock in a “full-persistent-mode” by setting "persist()" as first statement. This is to simulate a whole server file structure for several unit-tests in row. |
I agree with @andreas-roessler - we use nock to create an "emulator" of a remote system. Then we hit it with multiple requests. We need one response for /foo/bar and another for the rest of /foo/* - if the latter triggers for /foo/bar, it's all broken. So we define it in the order it needs to match. Always have and it's worked well. |
Shall we do this then?
|
IMO this is an anti-pattern, and they should use tools like Stubby, which does EXACTLY that. But if we decide to revert the change, I recommend adding an option to the persist function which enables new behavior and consider deprecating the anti-pattern behavior on the next major. |
Stubby looks interesting but it appears to require spinning up an external process does it not? Which is painful. And it can't do the one thing we require of nock and that's to be dynamic. I need to POST to create something, get back a random uuid and then be able to GET that uuid. To test CRUD operations on our end. Otherwise you end up having to start from scratch for each subpart of each test. I'm interested in finding out what is driving this change and what the anti-pattern is? If you have multiple endpoints in a hierarchy you need to know the deeper ones will match in preference to the higher level ones. Why is it bad to have the interceptors run in the order they're specified? Bad enough to warrant changing it and even worse than that proposing to deliberately remove that in a major release. I would normally say "if it's not broken..." so I'm keen to understanding why it's considered broken because, in its current form, the entire module appears unusable to us. @mikicho ? Genuine question - wanting to understand. (Mainly because we might be doing something wrong or poorly and could mitigate on our end by doing it right - other than recreating all the nocks between multiple steps of a single test case) |
I think I might have found out why this change was messing with us so much. Seems my guys were abusing regular expressions. Some adding of ^ and $ and [^/]* instead of .* and the occasional /? on the end (grrrr) to construct some far more exact matches seems to have solved this for us. Or at least we're doing things better so ordering changes won't affect us. Which is what we always should have been doing. Still interested in the pattern / anti-pattern discussion, though - unless you meant exactly what we were doing. |
I’m quite sure that I’m not aware of the full potential of nock and its concept but it seems to me that a mixture of persistent and non-persistent interceptors is hard to handle in principle. With the new behavior I wonder in which mixture scenario a persistent interceptor is a good choice without getting completely confused. If there is no more resistance from consumer's-side within the next weeks, it is ok for me to invest the effort of some days to adapt our unit tests by defining more specific path-matchers with extremely long Regexps. |
We found that ordering was changing when everything was persistent, I'm sure. |
It was just an example. You can use json-server or httpmock, which is very similar to nock and maybe what you are looking for. Potential better suite alternative list: https://www.npmjs.com/search?q=keywords%3Aserver%2C%20stub
Unlike other tools, Nock uses a stack to manage its interceptors, as noted here, interceptors are removed once they have been used.
😅 I wrote the previous phrase before reading this comment... I was there... this is why I stopped using the "whole server mock" approach, the debugging of a whole server with complex regex was painful.
I agree, and I'm sorry about it. But sincerely, I recommend you either embrace |
Just to be clear: it was not a matter of opinion, but a matter of insufficient test coverage, hence the ask for a test to avoid the same regression in the future. |
We have a mixture of persistent and non-persistent setups (even within one test file) depending on the unit test. I still do not know a practical use case in which a mix of persistent and non-persistent interceptors make sense, without getting confused with the new approach.
Does this mean that the there is no doubt about it that this change is a breaking change an should be reverted for this major version and an additional regression test has to be added to avoid such things happen again in future? What is the next action? I'm currently not allowed to contribute yet until I have finished a company-internal OS contribution training (definitely will do that eventually) |
2 cents from me as well: I'm open to understanding the reason for the change, and also try to embrace nock's philosophy :) Still, for now: we use "full persist mode" and have a catch-all interceptor, so after upgrading from 13.3.0 to 13.3.2, the second call to a specific endpoint is intercepted by the catch-all. That's why this patch version breaks a lot of tests for us. I would echo that the next action should be to revert the change for this major version. |
I still think these are the next steps.
I'll do a revert PR for v13.3.2 now as we seem to agree to do that. @mikicho if you depend on the |
We reverted this change. We can close this one. |
Please avoid duplicates
Reproducible test case
Code snipped added to "What happened?"
Nock Version
v13.3.2
Node Version
18.15.0
TypeScript Version
No response
What happened?
Hi dear nock-team,
with commit
8aab603
a new breaking change/behaviour has been introduced which crashes our tests of several projects.
It is reordering the interceptors which leads to a different sequence handling.
Would you be interested in contributing a fix?
The text was updated successfully, but these errors were encountered: