Today I want to share my view on writing tests in web development based on more than 10 years of experience. You will learn when and what kind of tests you should right and what is a best approach to it.

Why test?

That is the first and really good question to ask. There is a popular opinion that good developers always do TDD (Test driven development) where we write first failed test, then implementation for this test and check that our test is green.

The main problem is that everybody says that it's good but nobody is doing that. I saw literally 1-2 companies in more that 10 years that did TDD. So either it doesn't work or people don't know how to do it. So the main problem when you start development you will for sure change things. You will create and remove services and components, make sharable things, etc. It doesn't make a lot of sense to cover from the beginning things that you will change tomorrow. Or you should throw your tests away and write other tests.

But also there is a problem that other 99% companies don't test anything at all. They simply write code and fix bugs. But it can work only until certain point. When your codebase is big any change that you do will break other parts and produce other bugs. This is why starting from some point team fixes bugs 80% of the time and 20% implements new features.

It is simply not possible to change code without breaking things and it doesn't matter how good you are as a developer. So you need for sure to write tests when your code is more or less stable.

Will you deliver faster with or without tests?

That's the important and difficult question. Obviously all developers at the beginning will say that it is faster to develop without tests because you just spend time on code, you don't need to check if your tests are still working and spend time on updating them.

But it goes in the same direction as a typed language like Typescript for example. You have a big upfront cost. Your development will be slower. But with time the amount of time that you need to implement next feature or fixing a bug without breaking things will increase tremendously. It is completely possible for the whole team just to fix bugs and never see a stable project because they don't have any tests.

So in the long run you need tests. If you deliver a project in 2 weeks and forget about it or if your project is so simple that it's difficult to break something which changing, everything is splitted between different pages that you don't need tests.

What to test? Unit tests

There are lots of things you can test in code and even more when we talk about browsers and user interaction. Most popular way to test is unit tests where we test exactly the code that we wrote. It exists in almost all languages. Unit tests are amazing to check different cases of your code, it is easy to test as you test all service, component or function is isolation and it really helps to improve your understanding of the code especially if it was written by other developer. You simple write test cases for the function that you don't understand, you see outputs and your are sure that you don't break a function if you refactor it because you checked it's test cases.

So here are benefits of unit testing

• Tests in isolation
• Easy to test
• Improves code
• Easy to refactor

What to test? E2E tests

But it web it is more difficult because we have a DOM and websites and we want to test user interactions with the website which can be more tricky because browsers and different, you have different data everywhere. It would be nice to just open the page and test what user sees, what happens when user clicks on button and so on.

The most popular library for this is cypress. You can simply write in what browser what page needs to be loaded and write test cases where you test DOM elements on the screen.

But it can be really problematic to run such tests. On what environment will we run it? On development on local machine? On production? Every test will create something and pollute database so we need to have a possibility to clean it. We also need to authenticate user so we can check if he can create something and it is even more tricky to do all that in CI in isolated environment.

So it's not something that you setup and run in 10 minutes. It's a difficult ecosystem that you need to maintain correctly.

Test coverage

A lot of people who are obsessed with tests are also obsessed with having 100% coverage of their code. Which doesn't bring you anything except of cool number that you can show to your client. But test coverage tools are good helpers in identifying what files your already tested and if you wrote all necessary test cases. So as with any tool it can be useful but we should not think that project is doomed if our test coverage is not 100%.

Conclusion

Testing is just a tool which is extremely useful in long lasting and complex projects. But any project can live without any tests until the certain point. And obviously if you want to be a good developer you must know how to test your code using different frameworks and what to test, in this case if you find a company where they write tests and you know how to do it you are a better candidate there over the guy who can't do it.

And if you are interested how to spot a bad software development company make sure to check this post.