DEV Community

Cover image for Start with one test
Bruno Noriller
Bruno Noriller

Posted on • Originally published at Medium

Start with one test

Throwaway projects aside, would you say testing is important?

Tests are important but…

It takes too much time…

We don’t have time for that…

I don’t know how to…

I do it manually…

My code is perfect!

However…

Have you ever had the need to fix something for someone just for it to break it to someone else?

How about fearing touching the files someone else created?

How about it “just stopped working” and when you finally found out why it was because some dependency changed something (or someone changed a file you are dependent on)?

Are you debugging or manually testing, again the code you’ve been debugging and manually testing since last week?

And what happened was…

To lose a lot of time chasing a bug that appears out of nowhere or to dredge through the work of someone else.

Test is like coding

Remember learning to code?

Your first tests will be awful, but they will still help you.

Here’s an example:

GitHub logo Noriller / one-test

Start with one test!

One test!

If you don't have any tests, anything is already better than nothing.

So start with one test.

Check out and choose which one you prefer:

And then start testing one component, one process, one "happy path".

How to use this

I used pnpm here, so you need to have pnpm installed globally.

pnpm install

# unit tests
pnpm test

# e2e tests
pnpm test:cy
Enter fullscreen mode Exit fullscreen mode

Outro

Happy testing!




I purposely made this as naive as possible. The biggest problem is that it’s “flaky”, but there are others.

Being flaky means that changes will easily break the test, meaning you will have to fix the tests every time you change the code if you test them like this.

But… it will work, it will help and even save more time than if you were doing it all manually or just hoping it doesn’t break.

And as you learn how to test and best practices you’ll start refactoring your tests (yes, tests are also code that should be refactored) and making more resilient tests, with fewer bugs (yes, tests can also have bugs), also tests that test more than just if it’s working (example: you can test accessibility by using selectors that work with semantic tags and roles).


The more you test…

In my experience, the more I test and the better the coverage, the less I have to rely on manually using it on every change and even less I have to debug.

Not only that, everyone on the team benefits from those tests. They are already there and telling you what should be working and how. And when something breaks, it tells everyone exactly where.

If you get a tested piece of software, you don’t need to know and keep in your mind all the complex rules the code needs to work, so when you need to refactor or change it, you will always know if it's still working or not and be able to catch if the breaks on the test are intended or not.


So… what other benefits do you find with testing or what still holds you back from testing?


Photo by National Cancer Institute on Unsplash

Top comments (0)