I’m trying to adopt TDD in my daily programming practice. I use it at work very effectively, but I’m having trouble with my personal projects where I’m using some complex algorithms.
The particular algorithm that makes me ask this question is the Extended Kalman Filter. It’s complex enough that I’m not confident in the code I’ve written, but it’s simple enough that it’s hard to break up.
I could write a test for the algorithm with an input and the expected output, but I’ll do a lot of thrashing and shotgun coding in the middle because I don’t have confidence in those intermediate steps.
If you’ve worked with reasonable complex algorithms and use TDD, what is your approach?
3
TDD is not a substitute for design.
This is a common misconception about TDD, that you can somehow “grow” a coherent design from red-green-refactor. You can’t. Your tests still need to be guided by your design skills.
If you’re trying to figure out what to do between the input and output of your method under test, it probably means that you’re trying to do too much in a single method. Think about what those intermediate steps should do. Write tests for those intermediate steps, and write methods that pass those tests.
1
One can use TDD for complex algorithms. Write plenty of clear yet meaningful tests and use them to design your program. if there is randomization used in the algorithm use some sort of dependency injection and test randomization separately. TDD is one of the many methods you will use to write high quality algorithms: other being code reviews, logging etc..
I could write a test for the algorithm with an input and the expected
output,
Do not write “a” test.. TDD is not write one test at a time. Write multiple tests first that checks various bounds and standard inputs of the algorithm..
I’m new to TDD (read: I’m probably not doing it right), but it seems to be more suited to easily describable algorithms, when you can easily reason about which inputs match to what outputs.
When I’m doing more “I don’t know what’s the outcome gonna be yet” TDD hasn’t been very useful to me. What I do instead, I use asserts very liberally on small portions I know work how they should work so far. This way I don’t get stuck trying to code to a target that I’m not sure should is the valid target, but I get some protection, localizing the pain areas to smaller portions of the code.
Once the algorithm is sorted out for correctness (as in I am sure about at least some inputs->outputs for spot checking), then I go back and write a test. Then it’s much safer to go back and refactor, or optimize for speed or resource usage.
I would say this kind of thing is more suitable for RDD: Reading-Driven Development.
This is where you read in a book the algorithm for something complicated like a Kalman filter, and then translate that into an implementation in your target environment.
The disadvantage is that doing things that way means you don’t get test cases for free as part of the design process. On the other hand, something wll known like that almost certainly has an existing implementation (e.g. Commons Math). And then it’s straighforward to use that as a test oracle for your new implementation; all you need to worry about is that your set of test cases covers all paths in your code.
1