or, the āweāre not kidding, this is not in jest, you really should be testingā part.
after several cycles of scrubbing out bugs and fine-tuning your spectacular app, youāre going to start realizing that youāre running into the same class of bugs and problems. or, maybe you know all the pitfalls of your code, but the other members of the your team donāt and inadvertently create bugs. regardless of the reason, a robust testing methodology baked into your coding will help provide a safety net for all the things that could go wrong as you add more and more code to the app. (if the act of debugging your code is removing problems, then the act of programming must be the act of adding them in, eh? š)
Jest is built on top of the mature Jasmine project to be zero-configuration and much faster than its predecessor. itās built at Facebook so it also works really well with React which is the main recommendation of this guide as well.
to create tests, you create .js files within folders named __tests__. alternatively, you can create files with a .test.js or .spec.js suffix. it comes bundled with create-next-app by default. if it isnāt installed you can do so via:
npm install --save-dev jest
the basic form of a test involves just asserting that something is true or not. for example:
it('sums numbers', () => {expect(sum(1, 2)).toEqual(3);expect(sum(2, 2)).toEqual(4);});
to give you the ability to test React components, the Testing Library helps put simplify test writing.
to get a measurement on your code to see much your tests are actually examining your code, you can do the following:
npm test -- --coverage # (note extra -- in the middle)
a widely-used product in this space that you can utilize is coveralls. i hear good things about codecov too but havenāt tested it yet.
you can debug your tests via about:inspect URL in your Chrome browser. learn more on this technique here.
hereās a handy playground for creating and testing UI.
mentioned in CI section is the fact that you can setup a server so that you can ādogfoodā your app before it goes out to the public. testing can catch a lot of things but sometimes new classes of errors can only crop up with real-world use.
the latest hotness here is Puppeteer. this lets you automate your browser to navigate through your app by simulating clicking and typing into the browser. save this kind of testing for the very end ā itās thoroughly involved and expensive to maintain ā only very mature projects should consider this route. if you do start browser automation, you should also consider sticking to just one browser (either Chrome or Firefox). automating multiple browsers will only compound your headaches with this work! (historically, there was a project called PhantomJS and in the Firefox realm you have Selenium testing.)
cypress has also been making splashes here ā havenāt tested it yet but looks great. same goes for Playwright ā iām looking to evaluate that as well soon.
iāve personally tried over the years to maintain several tests suites involving screenshot testing and they usually all go to hell. if thereās one thing i would try to steer you away from it would be this. save yourself tears and from tearing out your hair ā itās not worth it. if youāre really bent on doing this you can check out Huxley although i havenāt personally tried this library and even Facebook has archived this project, which tells you something. as an alternative, another article recommends using Storybook but, again, iām going to stress that you shouldnāt go this route ā there be dragons!