Unit Testing The Algorithm - Not The Entire Possible Dataset
This morning I attended a very inspiring talk by Jim Weirich where he talked about the correct way to do unit testing. Someone (aka Skeptic) asked an interesting question during the Q & A and unfortunately it wasn't really answered. The lack of time and detail made it difficult for Jim to answer and he punted. I'm going to attempt to answer the question as I understand it (or as I want it to be).
If I understand the question correctly Skeptic was asking how to test an algorithm. His example was a system where forms were generated dynamically based on prior input. For example, if a user checked a checkbox on formA then formB contained a few extra fields. When submitting a form the system must be able to handle dealing with knowing what fields are there/not there. The concern was that there are so many combinations of forms and fields that testing each one would not be worth it.
I agree! So what would you do? Step back and think about the fundamental problem. Skeptic really wanted to test the fact that the system can deal with a missing field. It really doesn't matter that there are 5 possible combinations of fields or 50,000. If the algorithm for validating the missing field handling is correct you are likely in a good position.
Unit test the algorithm and not the entire dataset. Take a look at the prime factors kata for a really simple example of what I'm talking about.