Is there an option in Javascript's Mocha test runner to only run tests which failed on the previous run? Is there an easy way to implement that if not? There are a lot of words written about retrying flaky tests but thats not what I want. I want to run tests, see failures, make updates to the code, then automatically run only the previous failed tests to see if my changes fixed them
Found this https://github.com/segmentio/mocha-broken but integration into WebStorm wasn't streamlined enough so dropped it...
Might fit your needs though, worth a try
Related
Simple scenario, angular, unit testing and continuous deployment.
What can happen is that a developer finishes the unit test related to a component. During development time the developer uses the functions fdescribe() or fit() just to run those specific tests.
In a moment of distraction the developer commits and pushes and deploy is done on production, but fdescribe() or fit() was forgotten in the code.
Tests are not failing, but this brings a bad scenario in, basically all the regular tests are not running, but the traffic-light says GO and all deploy is done.
Is it possible to check that in the all unit tests any fdescribe() or fit() are called?
You can set a pre-commit Git Hook that will check that fdescribe() and fit() (and any code you don't want to be committed) aren't present in your test files.
Here's an example code you can find on githooks.
In your case, I think this pre-commit code could be very useful given that it will check all files in staging area that are added, modified or renamed but not deletions.
Mocha supports it.only syntax to reduce the amount of tests to run. In our team, a developer might use it.only temporally within a code base.
Now it happened that such an only test was approved and deployed by accident. This led the build server to happily run only one test and to declare that build a success.
My question now becomes: Is there a way to tell mocha:
It should only allow only on a developer's machine? Can it be make environment aware so that either all tests always run on a build machine or an only test case would also declare the job a failure.
(I know that there are different ways to reduce the amount of tests run by mocha. E.g. within WebStorm one can run a subset of tests within a project without changing code. The scope of the question is to allow for the fact that a developer might use it.only and they shall be free to do so. I want to detect if such a change might sneak its way into the codebase though.)
On your CI, you should run mocha with the forbid-only flag.
--forbid-only causes test marked with only to fail the suite
Depending on your setup it may look like:
mocha --require babel-register --recursive tests/unit --forbid-only
A developer still may chose to run the test suite without the flag.
Recent versions of IntelliJ IDEA support the execution of Jest tests.
I couldn't find an option (or even better a shortcut) to update snapshot tests within IntelliJ IDEA.
Is there an option/shortcut to update snapshots within IntelliJ IDEA?
What I have been doing is to right click on the failing Jest test and select the Create option in the pop-up menu to create a new run configuration for just that failing test.
I then add -u to the Jest options and run that specific test (once) to update the snapshot.
It is far from ideal, but you can keep them around for later, if you like, to re-run them with the -u option when needed.
I was wondering the same thing and I asked Jetbrains. They said this feature was requested and you can track the status of it here: https://youtrack.jetbrains.com/issue/WEB-26008
I'm not sure when it will be complete but looks like it is on their radar.
The -u option can be applied as a Jest run config default if you want it to be active for all Jest tests.
I started to learn ReactJS yesterday (to be used in my next product), I am willing to set up my dev environment but now I'm stuck with Jest...
Having a bluetooth lightbulb on my desk (already op with scripts etc..), I want to get a red light when my tests launched with jest --watch fail (see create-react-app from FB devs here)
The problem is, I don't know how to run a callback after the tests, it seems like no one ran into this issue on the interwebz, no solution found yet for me.
Update:
I am currently using a log file to grep:
lamp.rb
def ci
if File.readlines("path/jest.log").grep(/failed/).any?
File.truncate('path/jest.log', 0)
fail_jest # This method updates my lightbulb :) (red blink)
end
rescue
puts 'No jest log found :('
end
Launching my jest tests like this: unbuffer npm run test |& tee tmp/jest.log
I am still looking for a better solution !
Thanks for your help
Your problem is not specific to React or Jest. When your run jest tests, you are basically running a Node/npm command and when the tests fail the process exists with an unsuccessful exit code. This is the same mechanism used to make automated CI builds fail when tests don't pass. So I'd suggest you start your research from there and depending on your lightbulb's API, it should be straight forward to make it fire events whenever the process fails regardless of the reason.
I am looking for a way to make karma.js crash when my tests fail so that my build process gets interrupted since that is easier to monitor in a remote building server.
I am using mocha as a reporter and jasmine as the test processor engine.
Is there any option or particular variable in the karma.conf.js file maybe that would allow me to "crash on test fail"
There is no need for a "crash on failure".
Your build process should check the exit code of the Karma process that it launches. If all test pass, the code will be 0. If there is a test failure, the code will be non-zero. (I've just checked and it was 1 when I tried.)
You may be able to get a plugin for karma for your build server that will report the results of your tests.
For example, there's a plugin for karma/teamcity (karma-teamcity-reporter) which allows you to fail the build step, preventing the application from publishing if you have it set up that way.
you can use grunt as automation tool to run your karma test case so that whenever any grunt job(test case) failed it will by default stop execution.