We all write tests. And we always go for 100% coverage. Right?
This week, I'm answering
Jordi Bruin's question:How do you approach writing tests? Do you think of them beforehand?
When writing applications, we often come with a certain mindset related to tests:
1.
The production testerNever writes tests and uses the time to develop more and faster instead. He trusts that issues will be found during regular usage and testing of the app.
2. The minimum tester
Tests only the critical paths of the app or foundational business logic.
3. The 100% coverage seeker
Tests even those static strings for their output, as long as 100% coverage is reached.
4. The Test-Driven-Developer
Writes tests first and implementation after.
----
I don't think that there's a good or a bad version (I likely forgot about many different types of developers), but I think every type has its benefits and reasoning. I've worked at a Digital Agency in which time was tight. Writing tests was not possible w/o delaying the project. Now, at WeTransfer, we've got a lot more time to write tests, but we still don't seek 100% coverage.
In other words, you could say I'm a bit in the middle of 2 and 3. In my opinion, it's always important to write tests as it will help your future self with not (re-)introducing bugs. Yes, writing tests takes time, but it also takes time to fix bugs that you could've prevented with tests.
In my article
Unit Test Best Practices, I'm explaining why I think it's not important to reach 100% coverage. Doing so takes time and wouldn't always bring you to a better place.
So, how do you approach writing tests?
Today, I'm refactoring our syncing strategy in the
Collect by WeTransfer. Some tests are already in place, while new ones need to be written to cover new scenarios. Code coverage helps me to determine "weak spots" in my code. I can easily find which parts of the logic aren't tested, and I decide for myself which parts I really want to make sure are tested. In other words: "which parts I want to make sure don't break". Unit tests are a great way to give yourself confidence for releasing a new version of your app as you know that your core logic is working as expected.
But do you think about them beforehand?
Not always; it depends! Sometimes, I'm writing tests after finding a certain bug. The fact that the bug could occur means that the tests didn't capture it beforehand. When fixing a bug, I start by writing unit tests reproducing the bug. This helps me both verifying my fix, as well preventing this bug from happening again.
In terms of regular development, I often start by writing the implementation. I'm not a TDD type of developer, as tests would often not run initially, and it just doesn't fit my workflow. However, it does sometimes help to write tests to make it clear for yourself which scenarios your code needs to support. Once again: it totally depends.
----
In the end, in my opinion, there's no golden rule. I'm personally flexible to use the best approach for my current task. If there's one consistent outcome: I always write
some tests, and I encourage you to do the same.
Reach out to me on
Twitter to tell me what you think or to ask me a question for next week's SwiftLee Weekly.
Enjoy this week's edition!
