ArtemGovorov
commented
6 years ago This is indeed an exciting setup! Thanks for sharing.
And I add the node_modules to NODE_PATH like this:
This was causing the issues that you are observing, because it is confusing Jest (when ran by Wallaby). You also don't need to include any node_modules in your files.
Would there be any way to resolve node_modules in a way that honors the path of the file that does the require/import? How difficult is this?
No changes from our side are required.
You may just tell Jest (when running from wallaby) how to resolve node_modules by using the moduleDirectories setting. When running without wallaby, Jest is able to run without the setting, but Wallaby run Jest in its own cache dir, so the hit is required. In case of your mobile testing setup, you also need to clear the process.env.NODE_PATH = '';, because wallaby sets it to local node_modules by default (and it's not desirable in your case because you have react-apollo and a few other modules installed in both ./node_modules and ./mobileClient/node_modules).
This is the only/most important change(s) that you really need. Other than that, you may clean up your files list to get rid of node_modules where required, and only include what you need for your tests to run.
I have sent you 2 PRs with config changes: Mobile: https://github.com/TheBrainFamily/TheBrain2.0/pull/94 Web: https://github.com/TheBrainFamily/TheBrain2.0/pull/93
So your wallaby-mobile.js now looks very simple:
process.env.BABEL_ENV = "test"
process.env.ENZYME = true
process.env.NODE_ENV = "TESTING"
module.exports = (wallaby) => {
return {
debug: true,
testFramework: 'jest',
files: [
'mobileClient/**/*.js',
'!mobileClient/node_modules/**',
'server/src/**/*.js',
'!server/src/**/*.spec.js',
'testing/testHelpers/**/*.js',
'testingMobile/**/*.snap'
],
tests: [
'testingMobile/App.test.js',
],
compilers: {'**/*.js': wallaby.compilers.babel()},
env: {type: 'node'},
setup: function (wallaby) {
process.env.NODE_PATH = '';
const jestConfig = require('./package.json').jest;
jestConfig.moduleDirectories = [
'node_modules', '<rootDir>/server/node_modules', '<rootDir>/mobileClient/node_modules'
];
wallaby.testFramework.configure(jestConfig);
}
}
};and your wallaby-web.js is even simpler:
process.env.BABEL_ENV="test"
process.env.ENZYME=true
process.env.NODE_ENV="TESTING"
module.exports = (wallaby) => {
return {
debug: true,
testFramework: 'jest',
files: [
'client/src/**/*.js',
'client/tests/testHelpers/**/*.js',
'!client/src/**/*.test.js',
'server/src/**/*.js',
'!server/src/**/*.spec.js',
'cypress/integration/pageObjects/*.js',
'testing/testHelpers/**/*.js',
'clientEnzymeTest.json'
],
tests: [
'cypress/integration/landingPage.test.js',
],
compilers: {'**/*.js': wallaby.compilers.babel()},
env: {type: 'node'},
setup: function (wallaby) {
const jestConfig = require('./clientEnzymeTest');
jestConfig.moduleDirectories = [
'node_modules', '<rootDir>/server/node_modules', '<rootDir>/client/node_modules'
];
wallaby.testFramework.configure(jestConfig);
}// --config ./clientEnzymeTest.json
}
};
lgandecki
Issue description or question
When I have a structure:
And I add the node_modules to NODE_PATH like this:
I get errors.. while jest works.
(some background, feel free to skip @ArtemGovorov but I hope this will get you as excited about the possibility and wow factor here as we are :-) ) We've been building an example application that's a monorepo of decoupled apps, but where 1) you can test them in a way that breaking your server brakes tests for both mobile and web clients. 2) you run the same tests with enzyme, and cypress (the same exact file describes action, and behind the scenes with help of babel rewrites, they either use enzyme to perform them, or cypress). It works beautifully with jest. With a single package, when I was not reusing the server files to mock the graphql server on the web/mobile clients I was able to have fantastic, mind-blowing tests of type 2 (meaning, I have cypress e2e and also jest/enzyme tests with wallaby passing, I change something in one test file in wrong way - they both fail, also, when I change something in my script, they both fail and turn green in the same times.) It's easier to show than to explain and we are preparing to do just that in early Febraury, but we do want to give a huge shotout to wallabyjs there, if we can get this piece to work :)
In general - what this means, almost-end to end tests (with graphql server and in memory database, with no state shared between tests!) with wallaby, and immediate feedback. :) The only thing we are not testing here is whether the server can connect to the express server properly, and the way passport does the authorization, for that we will have a full-run e2e test that works on a unmocked client, running server, and real db running in a background. This will just ensure that everything is glued properly together, most of the other stuff is either pure logic, or frontend orchestration (like changing state/routes etc)
(/background)
Repro:
(they both should be green, as for circle build: https://circleci.com/gh/TheBrainFamily/TheBrain2.0/1009 )
and then use either wallaby-mobile.js or wallaby-web.js to see the problems
My guess is that all node_modules are treated as being on "the same level", so when I do require("graphql") in server/ and I included client/node_modules first (that also include graphql), it resolves the graphql from client/node_modules instead of server/node_modules causing some issues. Would there be any way to resolve node_modules in a way that honors the path of the file that does the require/import? How difficult is this?
Please let us know if there is any chance of having this supported in the next few weeks! I'm happy to help with any way I can. I actually made this prematurely open source just so you can play around with it.
Wallaby.js configuration file
https://github.com/TheBrainFamily/TheBrain2.0/blob/wallabyIssue/wallaby-mobile.js https://github.com/TheBrainFamily/TheBrain2.0/blob/wallabyIssue/wallaby-web.js
Code editor or IDE name and version
WebStorm
OS name and version
OSX