-
-
Notifications
You must be signed in to change notification settings - Fork 530
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
Server does not complete setup before next test suite executes in Mocha #637
Comments
@kettanaito You might be right, but I'm not 100% sure and it's kind of a pain to debug. By default, mocha runs sequentially and you have to opt-in to For example, in the repo as-is, if you remove the As an immediate solution that works with both sequential and parallel runs, what I'd recommend @cjones26 does is change the mocha configuration with these steps:
In the given repro, you'd add this file:
Update mocha config to include the new hooks file:
Refactor tests to look like:
and
As general guidance, I'd move the request handlers and server instance creation out into their own files so you can more easily reuse them in other places such as Storybook. |
@msutkowski -- you beat me to responding but yes it does appear to be something with the way that Mocha is working internally, and agree that it would be a pain to debug. I have not looked into the implementation of the functions, but my thought was that it could be helpful if As for your suggestion above, I believe this will work for our use case and I will refactor our real project (not the provided sample) in order to validate this. Thanks! |
Awesome! Let us know how it goes. I'm assuming it'll work as expected, and if so, I'll go ahead and open a PR for a mocha example and/or recipe for future users. |
@msutkowski -- the changes work....but only when we are not in watch mode. Once we run in watch mode and attempt to make any changes, the entire thing comes crashing down as shown here: Do you have any other suggestions, or perhaps any thoughts on my suggestion earlier, regarding returning a promise from the Thanks again! |
Okay, I think I have the right solution this time: https://mochajs.org/#global-fixtures, which as documented, is exactly how Instead of import { server } from "./setupServer"; // `createServer` code moved here as mentioned in previous comment
export function mochaGlobalSetup() {
server.listen();
server.printHandlers(); // optional, but helpful!
console.log(`msw server started!`);
}
export function mochaGlobalTeardown() {
server.close();
console.log("server stopped!");
} Then in your individual tests, just call References: mochajs/mocha#4347 - looks like this lead to the concept of global fixtures released here: https://github.com/mochajs/mocha/releases/tag/v8.2.0 |
@msutkowski -- ahhh, it's extremely close to working. Unfortunately, when we are using watch mode, if a handler is overridden, on save the
|
An update here--something funky is going on with node-request-interceptor (as suggested initially by @kettanaito). After saving repeatedly in watch mode, I begin receiving the following warning:
Clearly setupServer is being called multiple times--I will look further into this in the next few hours to see what I can find out. |
@cjones26 Sorry about the delay - I was doing some debugging on this yesterday, but had to stop. I'm going to push up my forked repo this afternoon. It's possible that NRI is part of the problem, but there is also just an issue with the test setup and how mocha is running things. For example, even if you make tests async, render and use a util like |
@msutkowski no worries at all! And completely understood--I would agree that we need to eliminate Mocha setup as the cause before pointing fingers at NRI. I will continue playing around to see whether I can resolve the issue as well. |
@cjones26 PR opened here: cjones26/mocha-ref#2 with notes. That works, but it still seems strange to me. I'm hoping @kettanaito, @marcosvega91 or @timdeschryver might have an idea of a better implementation. |
@msutkowski I have looked into the code and update it a little bit using the before and after function in a global scope. I have add my code here. Let me know what you think |
@marcosvega91 Thanks again! I merged that into my repo and into the PR for @cjones26. I think this is as good as we're going to get for right now. We will have to investigate supporting parallel mode, which may or may not have to do with #474 as @kettanaito said :) |
@msutkowski @marcosvega91 -- thanks for all the help on this one. What was the exact change which allowed this to start working properly? Was it moving around the setup in .mocharc, or was it using Common JS import style instead of ES6 style so that the server instance was cached properly by Mocha? Also, on a side note these changes do work properly in our production project as well 🍾 🥳 ! |
@cjones26 The magic here is the usage of the This behavior is slightly different than what I did originally where I created the server once, then set it to global. Either works, but this is the best we can do for now. We're going to continue to research supporting parallel mode - if we resolve that, I'll let you know so you can update if necessary. Thanks again for providing this issue! |
@msutkowski -- sure thing -- as of now I am sure we are fine and won't need parallel mode. Thanks again, closing this out. |
Environment
Request handlers
Note: I have created a repo displaying the behavior here.
App.test.js
Child.test.js
Actual request
The actual request is simply performed on mount via the Fetch API (in our tests we are utilizing the isomorphic-fetch library to polyfill Fetch for Node).
Current behavior
If we are running two test suites consecutively, in this case, App.test.js and then Child.test.js in quick succession, the second server is not fully set up before the test executes, resulting in something like this:
Expected behavior
Screenshots
Failed test:
The text was updated successfully, but these errors were encountered: