One guideline to test them all — Part 1
Introduction
Ok. I’ll take a bit of your time now, but I want to assure you I tried my best to make it worthwhile. Grab your tea or coffee and let’s start.
I’ve spent a huge portion of my last 5 years writing tests for javascript applications. I didn’t get into testing through my own personal interest, but mainly because, let’s say… others in the team were not that excited about it :) And they had good reasons for that.
However, It may sound a bit weird but I love testing for a long while now, I enjoy it and I think it started to like me back recently. In this article series I’d like to share a handbook that has taught me how to listen to my tests, what did my tests say about my code, and how they eventually made me a better developer.
Please note that all the statements in this article series, if not referenced, are based on my own professional experience and my own observations. I’d be more than happy to hear your feedback, criticism, ideas, and experience.
The main source of pain
Testing is one of the most controversial and opinionated topics in the development world. Not because it’s complicated, but because it’s not standardized. I think this is also the main reason that makes testing painful for some of us.
For instance, TC39 is doing a great job of standardizing Javascript. Thanks to their effort, in recent years Javascript became very powerful and a lot of fun to use. As a result, it’s the most popular programming language on the planet. (Of course, also thanks to great Javascript community and especially V8 team to make mass adoption way easier.)
Unfortunately, there are still no standard definitions for testing practices and there is no committee like TC39 who is working on it. If you google the test types, you’ll see there are hundreds of them (and most of them make sense in their own way). Even unit tests — which I think you have heard the most — have several different definitions.
Because of that, even in a small team in a small company, each developer’s understanding of testing is different, so they write code and tests in their own way. Eventually, we end up having code that is not test friendly and having brittle tests that fail on the slightest change or randomly, or do not fail at all which is even scarier.
Especially if there is a lack of team management, after a while, we may lose track of which parts of the product were tested and how they were tested. We may start questioning what was faked, what was tested with unit tests and what is part of integration tests. We might wonder if the code coverage still reflects the quality of the tests, etc.? The confidence in tests often decreases over time. At some point maintaining tests can become so exhausting or frustrating that you don’t want to touch your own tests or even source code.
(One could say there are other factors that also make testing painful, for instance, never-ending refactorings. But I would say, having to constantly refactor code is a sign of bad project planning and management. This does not only make testing painful but also the whole development journey. Therefore, I won’t be covering this subject in this series.)
I think, because of the frictions I mentioned above, most developers are reluctant to write tests and avoid thinking about testing before they start to write their code.
I hope we are going to change this situation in the near future, together!
The definitions/rules/tips in this article series are mostly an aggregation and synthesis of a great number of articles, books, and talks which were written/given by amazing people in the Javascript and Open Source community, and a bit of my own development experience.
This article series is my attempt to give you a new perspective on testing. Hopefully, in the end, we will have a common approach to test our products, we will have absolute confidence in our tests and maintaining tests will become way easier for us.
Ok. Ready. Let’s start with The Anatomy of a Product.
