The Power of One Test

A developer experience and quality control measure I take on programs I’m building, even small ones, is always to write at least one test.

Here’s an example, from this blog:

// cypress/e2e/index.cy.js
it('shows the homepage', () => {
  cy.visit('/');

  cy.get('article').should('have.length', 10);
});

The test loads the homepage and confirms ten articles. The test framework, Cypress, is inconsequential– the point is the test.

Should we write tests? What kind, and how many? It’s easy to overthink it; don’t. The difference between zero tests and one is massive.

Despite its brevity, this little test catches a lot. By loading the app and checking the main thing a blog should do— show articles— a surprising number of mistakes and strange behaviors never make it to production.

My typical timing for writing this test is a bit later than I probably should. Better late than never. It starts paying for itself immediately because there’s something to protect.

I don’t even need continuous integration; just run the test locally before pushing to production:

npm run test && git push

Yes, you can keep it that simple.

On a team, adding one test is a milestone. People see it, get inspired, and add more. Soon, you have a test suite. It starts with one test.