Loading...

​​​🃏​ testing

​​or, the “we’re not kidding, this is not in jest, you really should be testing” part.

​​

​​prev: performance

​​table of contents

​​next: the future and decentralization

​​tl;dr

• ​​intro: write your damn tests.

• ​​testing framework: Jest, Testing Library, coveralls (codecov), about:inspect​

• ​​canary server

• ​​browser automation: Puppeteer, cypress, Playwright

• ​​screenshot testing: the white whale: just don’t do it.

• ​​others: jest-dom, Sikuli Script, Appium, Sauce Labs

• ​​resources: Jest reference (Jest matchers), Overview of testing in 2018

​​

​​

​​intro

​​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? ​😛​)

​​

​​

​​testing framework

​​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.

​​

​​getting setup

​​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

​​

​​how to write basic tests

​​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);

​​});

​​

​​testing components

​​to give you the ability to test React components, the Testing Library helps put simplify test writing.

​​

​​coverage

​​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.

​​

​​debugging tests in Chrome

​​you can debug your tests via about:inspect​ URL in your Chrome browser. learn more on this technique here.

​​

​​playground

​​here’s a handy playground for creating and testing UI.

​​

​​

​​canary server

​​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.

​​