Tests are a good way to document your own code and to block yourself and colleagues from doing something that is not expected by business. TDD is an even better way to do that. But sometimes doing TDD the hard-core ways is boring so I want to improve the process a little bit.
What is TDD?
TDD (Test-driven Development), in short, is about creating tests before creating actual implementation. So that when receiving requirements of a new software functionality, we create small and specific test cases which would of course fail at the first time when we run the tests. We then have to implement the functionality until all tests pass. And repeat that process until the whole functionality with all scenarios is covered.
Doing TDD the hard-core way
Some tutorials on the internet suggest you to create test files before creating implementation files. In the world of OOP, an implementation is usually a class. So that when creating a test, we have to type every character of the class name and its function names even though that class doesn’t exist yet. That is boring and not very productive. It’s also a waste of time especially when we have very good tooling support to generate and autocomplete code nowadays.
Doing TDD in a balanced way
When receiving requirements:
– I would think about the overview of the components/services I’m going to develop.
– Then I would model the implementation by creating interfaces with behaviors I want to have. If you don’t think that interfaces are necessary in some cases, it’s fine to not create them. But usually, interfaces are a good way to achieve high level of abstraction.
– Then I would create an empty class file. If that class implements an interface, it’s super easy to generate empty methods using an IDE.
– Now the “normal” TDD happens. It’s time to create a test file with cases. Since I would have autocompletion of class name and its methods, it’s time to focus on test cases rather than typing boring characters.
There is no conclusion. Make your own developer life easier.