TDD or “Test after Writing”?
I’m sure most that are reading this already know what TDD stands for, but to those that don’t know it’s termed as:
Test Driven Development
The basic idea is somple. When you write your code, you – well, don’t – you write the test first, then write the code. There are a few reasons for this:
- Code is better guaranteed to be covered.
- You can think through your problem, as you’re writing it.
TDD works great and all, if you really know what you’re working on – what the end project is going to be, and have the general design built. Many people, including myself, want to see more immediate results rather than spending time writing tests first.
As I was writing my Common Lisp library for interfacing with git (will provide links later), I wanted to write unit tests for my code. I feel that writing the tests before the code would have not worked. There’s just little/no way for me to really know the structure given my current experience and understanding of Lisp in general. Waiting until the end of the library to write tests would also be equally stupid, because that’s a lot of time invested and likely full rewrites needed to help make code testable.
The area I’m advocating at this point is a “middle ground” to the two testing methods. I found for the Lisp library, that I could do this pretty simply by thinking of:
- What are my chunks of functionality?
- Are my functions doing one and only one thing (really well?)
For each chunk then, what I’ve been doing is the following iterative development:
- Write the code first
- Start writing tests for the fuctionality (denoted by comments if needed)
- Writing one test for each function.
What this has done for me is allowed me to think of my code in a smaller scale – each node of functionality has a testable purpose now. So my iterative development has been something like:
- Write code
- Write test for the code
- Rewrite code to be more testable (usually if a test has more than one assert in it or a totally different assert than what’s necessary)
- Write tests for the new split-out code (basically just split out what I was testing before)
- Rewrite code again to make it more testable
…etc, etc until it’s “good enough”
I found that this helps me with great code coverage without forcing me to really go full TDD – which is really hard to grasp. It may be worth trying for some others who want to improve testing but don’t feel the jump to TDD is really in their grasp.
