DEV Community

Cover image for Always write at least 1 end-to-end test. You'll love it, I promise.
Michał Gacka for 3dayweek.dev

Posted on • Edited on • Originally published at 3dayweek.dev

Always write at least 1 end-to-end test. You'll love it, I promise.

The cover image shows you how I felt the first time I ran an end-to-end test of a web service I was developing. You can feel like that too. If you always write at least one end-to-end test as soon as you start developing a new project or a module in your project. Why?

Why?

Because even in the early stages of development it will save you a lot of headaches and time: you won't have to check manually if things work every time you make changes to the code.

I shed a tear every time I think about how much time I've spent in my early dev years having to run the code and check that things work every time I changed an env variable name or fixed a bunch of linting errors.

Bonuses

  • by being lazy like that, you'll join the high echelons of programmers who have the test framework always set up and ready to accommodate more tests when you feel fancy enough to add some
  • if you're anything like me and you tend to postpone writing tests on hobby projects, following this principle will help you conceptualize the problem as not-a-big-deal-at-all since you only promised to add 1 test (the rest will eventually follow)

What kind of test to write?

For a front-end, it's nice usually nice to have some kind of simple click-through with a login step (if your application consists of such) and making sure that all the views/pages are accessible and rendered. For a micro-service or an API, it's great to have it accept some data and check the response or that it saved things in the database correctly.

Remember git hooks

You got this far in automating something that takes your time unnecessarily. Then why run the npm test command manually? Husky makes git hooks simple and fun. You just write a simple script, call it pre-push and your tests will run automatically before the code gets pushed to the remote.

Remember Docker

Synchronizing applications and services for testing can be a headache so make sure to have a nice and clean docker setup so you can easily spin up containers that depend on each other for testing purposes.

And if you're not on the Docker train yet, you should definitely incorporate DevOps skills into your practice. It's a must.

Top comments (2)

Collapse
 
ovid profile image
Ovid

I'm a huge fan of tests like this. If the test loads some fixtures, logs into a site, navigates to a reports page, and selects some reports and you test the results returned are correct, you've also exercised the authentication, authorization, navigation, and tons of other bits of code, even if you haven't tested them.

When you have a few deep integration tests like that, you quickly learn to appreciate the errors they'll pick up that other tests cannot because they're testing things in isolation—a state your full code tends not to run in.

Collapse
 
m3h0w profile image
Michał Gacka

Exactly <3 I've only realized this lately. Thanks for chipping in and helping to spread the word so others have an easier life :)