I'm refactoring one backend at my company and I'm modularizing it as much as possible. My structure can be defined as a monorepo composed of several local submodules and one or two main modules that requires them(the submodules). Let's illustrate this:
root
main
package.json
stuff that uses submoduleA
stuff that uses submoduleB
test
modules
submoduleA
package.json
code
test
submoduleB
package.json
test
As you can see, each module has it's own tests, package.json, and dependencies. Everything works flawlessly within them (running npm test inside the folder of a module, for example). I'm using lab and code for testing.
What I want is to be able to do is going to the root of the project, run npm test and run all the tests for all the submodules and the main module. Basically run all the test under any test folder in one go.
The problems that I found so far are:
- Currently only the files under the target test directory are being run. I don't even know how to run all the test at once. My command looks like lab src/main/test --reporter console --threshold 100 --assert code
What I'm doing now is putting all the test under the same test directory and make relative requirements for everything. This is very inconvenient because makes test fragile with all those ../../../some/away/path requires and that stuff.
Any advice for keeping the code modular, and being able to run all the test at once will be very welcome. Thank you very much.
I asked this a week ago on hapijs repository, so if you want to answer there too it would be fine: https://github.com/hapijs/discuss/issues/397
I would suggest making submoduleA and submoduleB stand alone node modules, then you can install and use with the main module when required. This way you are testing each part in isolation and then together which should yield the same outcome and will enable you to run tests more easier.
Related
I have a build/ folder that gets autogenerated by a babel process in a package.json. It has several .js files, including in sub-folders. In the root is a file, main.js, which is something of a demo / testbed for the project, that instantiates various ES6 classes and tries out various functions. It currently runs without crashing.
Call it a poor man's end-2-end test. I'm trying to move quickly with what could be throw away code.
I don't have any formal tests. I don't want to write any formal tests for this codebase. But I am interested in knowing how much of the code in build/ is being touched currently by my demo, main.js.
How can I generate a code coverage report for this scenario, using nyc?
If that's not actually easy (all tutorials I see seem to involve instrumenting pre-existing unit tests from a mainstream testing framework), what nyc alternative would make this easy?
I tried
npm install nyc --save-dev
npx nyc node build/main.js
but it claimed 0 lines/files.
With thanks to What is instrumentation in nyc istanbul?, it was actually simple. From the root, where my package.json and build/ folder were:
npx nyc instrument build coverage
npx nyc --reporter=text --report-dir=./nyc_output node build/main.js
all necessary folders (coverage, nyc_output) were auto-created (though it made .nyc_output/ for some reason)
I just implemented a Jhipster module to provide Maven site generation as well as maven release process within Jhipster.
I implemented mocha tests to verify that files are generated (which pass), but it looks like they aren't generated in a real scaffolded context (if you have any clue on the error, I would be really thankful).
The only way I found to test that module with a scaffolded sample is to publish it in the npm registry in order to be able to select it in module choices radio, but it's not really a good option, as it exposes a non working module on the Jhipster marketplace (I'm really sorry about it).
To test a module locally, do the following:
run npm link in your module directory
generate a project
run npm link generator-jhipster-enterprise-pom in your project
Now when you run yo jhipster-enterprise-pom it will use your local code instead of requiring installation from npmjs.
Looking at your module's code, it looks like you renamed the app folder to server. A yeoman generator runs the code found in the app folder which is why your local test is failing. According to the Writing Your Own Yeoman Generator docs:
The default generator used when you call yo name is the app generator. This must be contained within the app/ directory.
It's currently accessible by running yo jhipster-enterprise-pom:server but I imagine you don't want the :server included in the default command.
Currently I am testing a React node application, and have all my tests in the root/tests folder, with components in separate folders pertaining to their function.
I have 10+ folders and 100+ tests, and would like to 'watch' a single folder while I write a test for a new component.
Currently, I am using
npm run test:watch
Which is working brilliantly, however, not only is there a lot of overhead re-running the 100 other tests not related to my new component, it's also hard to weed through all the feedback to see the results of my current test.
Is there a nice command to only watch the directory of my new test, or even the test file?
You can pass mocha test directory to the npm command:
npm run test:watch -- root/tests/subfolder
However it might depend on how your test script test:watch is defined.
All of the unit testing frameworks that I know of / can find require a test runner.
They all require you to globally install and run some program that runs your tests. Is there a well supported testing framework that can run as an npm require() ?
I need one like this because I want to be able to debug my tests, and it is much easier for me to do this though webstorm. Also, the project I'm working on is very small and I don't want to get fancy
The node.js project itself simply uses the built-in assert module and JavaScript exceptions. They have a fairly straightforward script that runs every .js file in a directory tree and if the file doesn't throw any exceptions, the test is considered passing. You could use something like that.
However, although most frameworks do have a command line runner, you absolutely never need to install them (or anything) with -g. If you understand the basic concept of the unix PATH environment variable, you can npm install --save-dev mocha (for example) and then run your tests with ./node_modules/.bin/mocha. No -g required.
See also http://peterlyons.com/problog/2012/09/managing-per-project-interpreters-and-the-path
I'm using jasmine-node to test my Meteor application and I want to use the auto-test feature so I don't have to rerun the tests all the time by myself.
My meteor application folder structure is like this:
server
foo.coffee
tests
foo.spec.coffee
And with the spec file I want to test code which is located in foo.coffee. I start jasmine-node with this args:
jasmine-node ./ --autotest --coffee --test-dir tests
And now I would assume that the autotest feature will react on all changes in the root folder but it just reacts on changes in the test folder. And I can't start it in the root folder because I get an error in the .meteor files (and I don't want to have jasmine testing/including the meteor code anyway).
So I want to have jasmine rerun the tests even if I change code in the server folder. How can I achieve that?
Use the --watch parameter along with --autotest and specify the directories that contain whatever files you want to have watched.