After reading the great blog article from Johannes Link about property testing in Kotlin, I was inclined trying it out. Having written property tests with kotest before, I was curious what I was missing and how much I would like a specialized property testing framework.
From my experience, when introducing mocks to your testing, it is easy to get messy, hard to maintain code. The 4 heuristics I’d like to present come from my experience with Outside-In designed artifacts that might not be right. Keep in mind that these are not meant to be a path of virtue that I must slavishly follow. I often violate them and still feel that the code is good (enough).
I want to accuse someone for writing bad code. This person has written lots of crap for about 7-8 years. Little time went into refactoring and even less into automated tests. When I look at his code my first thought is “what the hell was this guy thinking?”. In many cases his approach to software design has proven to be harmful for me. For example, when forced to fix a bug that was introduced by my bugfix because I did not understand the code well enough.
After using TDD at work for about 2.5 years, I finally feel that while I still need more practice I am no longer a novice. I am confident enough to post some advices that come from common pitfalls I’ve encountered when still at beginner level. While they might be obvious to TDD experts I often notice similar mistakes other beginners make. So I thought that I might write as well them down.