You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, the HTTP server objects need to be undef'd after each test, otherwise you end up with collisions. This can be most easily demonstrated if you setup several tests that expect a 200 response, and several tests that expect other responses. Server instances built to handle test 1 may respond to test 2, etc. Better isolation is required in order to make assure reliability. It appears that the current workaround required that you only ever perform one test using unexpected-express per test file.
The text was updated successfully, but these errors were encountered:
So I guess I agree with the point you're making. Is that what you mean? Would you suggest changing something in the implementation or documentation so as to encourage people to use the library like that?
Hi @papandreou,
I'm not sure your example case fully address what I'm describing (as far as I can tell). I hesitated in posting this before I had a minimal example to include, which I'll have once I finish up items related to my immediate deadlines. IN the meantime, I'll look over the custom assertion example again to see if I've missed something.
By default, the HTTP server objects need to be undef'd after each test, otherwise you end up with collisions. This can be most easily demonstrated if you setup several tests that expect a 200 response, and several tests that expect other responses. Server instances built to handle test 1 may respond to test 2, etc. Better isolation is required in order to make assure reliability. It appears that the current workaround required that you only ever perform one test using unexpected-express per test file.
The text was updated successfully, but these errors were encountered: