It's safe to say that testing in the front-end world has grown over the past five years.

Jest has stolen the scene in the unit testing world, earning over 20,000 stars on Github and being the subject of many popular conference talks.

On the other side, tools like WebdriverIO, Protractor and Cypress.io are popularizing the concept of UI testing.

There are more options than ever for writing tests, and more pressure than ever to have bug-free code.

So why in world would you not write tests?

User testing comes first

There's no point in writing a test if you haven't user tested your site.

When starting clean on a new project, it's incredibly tempting to commit to testing from the beginning. But the most important testing we can start with is user validation of the functionality.

Any test you write will be worthless when the functionality shifts, and it will after user feedback.

So before spending time writing assertions, test your assumptions about the user interaction on your site.

Unclear Architecture

The front-end world is rapidly changing with new libraries popping up on a daily basis.

This leaves many of us starting projects utilizing tools we've never used before.

Writing tests in Jest is not trivial. Especially when starting out.

• How do mocks work?
• What's shallow rendering?
• Do I mock or do I import?
• Should I use Enzyme and Puppeteer and CICD and so on?

It's impossible to answer these questions when you're this fresh to a library.

Instead, take some time to learn what the architecture really looks like. Give yourself permission to write untested code.

Assume you'll be more effective waiting on tests than trying to jam them in up-front.

Opportunity Cost

You're not paid to write tests. Tests only serve the application they're testing. If app is useless, tests won't help.

If you're working on a side project for a tool that no one uses, spending time writing tests takes away from time spent on more important tasks, like getting people to use your work.

Users don't care whether you have good unit tests. There's no difference between an unused tool and an unused unit tested tool.

Let yourself have untested code. Worry about that problem when it actually becomes one.

Finish the system

Don't write more tests when you're not using the ones you have.

If you have 500 unit tests, but never put in the time to integrate them in your build and deployment process, you have 500 useless tests. Writing 500 more won't help.

Your tests should run on every code push. They should run before every deploy. Every developer on the team should see that the tests passed or failed.

If that's not true, then you shouldn't be writing more tests. You should be taking advantage of the tests you have.

Why test then?

Testing is incredibly useful.

They can prevent many stupid little mistakes from making it to production.

They can guide your coding process, helping your write better code.

But there's no good way around the effort tests take to write.

So ask yourself:

• Are unit/UI tests really what's most important at this time?
• Is the project in a good spot for writing them?
• Are we using the tests we already have?

Be honest with yourself and your project.

Tests are like a garden. Don't try planting in the middle of winter.

Header Photo by Isaiah Rustad on Unsplash