It is quite normal to see programmers who hate to write any type of test in their code. As a part of a short-term mindset, focused just on delivering new things, they really prefer (or are obligated by their company) to just do some manual tests and consider the task done. Their main goal during the work is to push the code to production or to report to someone. For these developers and companies, finishing a new feature is to code as fast as possible, so they won’t have to look at this chunk of code anymore. However, a bad implementation will demand time and attention in the nearest future, sooner than expected.
When a programmer decides to code a new feature in their project, without doing tests on it, this implementation is cursed to be revisited more frequently — to fix bugs, to review if everything still works, to see if some dependency changed, and a lot of other reasons you probably already know. Each time it happens will be more painful, even worse if you weren’t responsible for the initial implementation, especially because you have no context and no tests to guide you.
When you are coding a new use case is expected to you clearly have in your mind what scenarios this feature will handle. Look into the worst-case scenario or the best possible outcome your code will face. We all know about the importance of good documentation and clean code as a way to keep the code more readable and easy for the next developer, but there is no way to keep your implementation with all that information if you don’t create tests for it.
If you are in a team, you’ll discuss with the product team to understand explicitly what he wants to achieve. You can receive inputs about coming features you don’t know yet but can be smart to be prepared for this scalability. You’ll also receive code reviews from colleagues, and they can ask, for example:
“What is expected if the lifecycle of some component is destroyed during the process of some function?”. Looks like a test scenario, right? If you don’t do it, maybe the team just will figure it out when in production, at 9 pm, Friday.
The next developer working on that maybe doesn’t have all the knowledge about input possibilities, error handling, relevant dependencies, edgy cases, and business logic behind this. The developer who actually started the implementation had. The only way to keep this knowledge shared is by doing tests for it, covering as much as possible all cases from the beginning, and keeping the high code coverage when new improvements appear. It’s a way to learn about the feature, from a technical point of view.
Creating tests is at the same time an act of concern to guarantee your feature keeps working for different scenarios, but also to preserve the knowledge about what to expect when running your code. Tests will maintain this know-how between all the developers, who one day can be working on this feature. There is no doubt about why a class or function exists when a test is created exposing the expected behavior, and all that can be easily found in the code.
A good test (properly named and organized) will guarantee there are no assumptions in your implementation. You know exactly what to expect and how it will happen, event by event, line by line, from the input to the output. The product team needs to have this clarity from a user perspective, you need to have this clarity from a technical perspective.
I know, you are tired to hear about TDD but never actually being able to do it as you wanted — but this text is not about it. You don’t need to do test-driven development to exercise a test-oriented mindset. The only way to have a complete view of your algorithm is when you do tests. And believe me, thinking about how your algorithm will work in different contexts can be fun and you’ll learn a lot about coding by doing it.
