Some basics I’ve learned about testing.
Writing tests is a simple and easy practice, and writing good tests is a difficult part of that.
I rewrote this sentence at least a few of times:
Writing tests is a simple and easy practice, and writing good tests is a difficult part of that.
I want to make a point of keeping the ideas of as a simple and easy practice with having a difficult part mutually exclusive of each other and to the whole process of writing tests. That helps me to hold myself more accountable to continually write tests. Note that the following thoughts aren’t formalities or religiously held beliefs; they are reflective of what I currently see as my skills, understanding, and experiences. I welcome and encourage feedback for all of the ideas presented here and to learn more through your shared experiences and opinions as well.
How do we define good and bad tests?
During one of my introductory courses, I once heard an instructor say that it is more important to write bad tests than to skip writing tests all together. It doesn’t matter if they are good, so long as you are writing tests. I wish I could recall the specific memory, but at least the idea has stuck with me.
This is a bad test, but why?
So what would that instructor have said about this example? If I was teaching a class, I would use this example to start building an understanding of quality. Yes, this is an exaggerated example, but when breaking down my own tests, sometimes I find that they are just fancy-looking versions of nearly this! Some of the reasons this is a bad test:
- It proves a tautology, and it does so without exercising any business logic.
- It is poorly named, especially within the context of our application.
- It yields a docblock without providing extra context or value.
A bad test doesn’t require that all of these things be present. We are trying to look at how we can better the quality of a test, and these are some good things to start addressing.
So where is the example of a better test?
I tried to think of a good example test, but I’m going to take the easy way out here and say that it depends. That’s one of the lessons I’ve come to understand more as I continue to work on more dynamic and larger scale applications. To an extent, a full example of good tests is a well tested example application itself. Good tests have purpose and meaning, so there must be underlying code that they exercise. Though, there are some good things to try to do when writing your tests:
- Write to cover all cases rather than all lines.
- Write each test so that it has a narrow scope and few assertions.
- Write with purpose in both your naming and intention.
- Write a failing test first.
Where do you stand in your journey towards better testing?
I have not done my due diligence when it comes to testing lately. I came to realize this more harshly after doing some upgrades across different services: one has a great test-suite and the other simply does not. With the well tested service, there was so much power in being able to make a change, run the tests, and feel confident about moving onto the next task. For the less than well tested service, I have to be much more diligent and cautious of changes and updates while exercising the application itself rather than run the tests. Truly, I should be writing tests along with the upgrade.
Think of how long it was between when you last wrote a test and wrote a line of code. Do you have confidence that a change in application logic will break your tests? Have you mocked things to where it no longer matters? I hope this got you thinking of questions like this and hopeful of better honing your skills.
