The benefits that you get from testing your code will never cease to amaze me.
I was working on a new feature and part of it required changing one of our oldest classes. The class was still in Java so I decided, before doing any other work, to convert it to Kotlin. There were no tests so my first step was to add them and make sure that the conversion wasn’t going to break anything.
The class is a simple configuration one that
- setups a couple of its fields upon construction and
- exposes its validity state
something like this
but with many more fields.
So I started writing tests to cover all cases and the one that failed immediately was
at first I thought I had an error in the test but looking closely at the production code I saw the problem. Actually the problems. Plural:
- Even thought in this case its subtle, the constructor is violating the SRP. It initializes the fields and makes a decision on what will be exposed. This is a job for the getter.
- Which brings us to the second problem. Getters are great way to expose information allowing us to make internal changes without breaking anything outside the class. They help us decouple ourselves from the classes that consume us.
By using the getters instead of the fields, as in
isValid, we couple the class with itself making it depend on what will be exposed and not the actual internal state of the class.
For the record the fix is
and we managed to figure it out by writing a small, simple test.
Having a quick feedback loop is a great way to keep yourself focused on the end result and to make less mistakes on the way. In our profession this is achieved with tests.
This bug was hiding for quite some time so the loop in this implementation was literally years!
Aim for shorter time periods! Seconds is the best and to do that is to write the test along side the production code.
I strongly encourage you to follow TDD but it doesn’t matter if its not your cup of tea. Write it after the production code, just do it immediately after.