I’m having trouble developing unit testing approaches to testing both if the “code does what I want it to do”, and testing “does my code work”.
For example, I’m writing code to validate input that will be inserted into a database table, so I need to test if my code does what I want it to do – Good input is accepted, bad input is rejected. Here’s some of the code, in VB.NET:
'Let's check if we are going to update all the fields that must be updated...
If record.table.RequiredMustBeSuplied IsNot Nothing Then
For Each req In record.table.RequiredMustBeSuplied
If query.UpdateFields(req.Key).value Is Nothing Then
Throw New ArgumentNullException
End If
Next
End If
So, for my unit test I would pass in a query without the proper update fields and expect that it would result in a ArgumentNullException, and a corresponding test that passes. The problem that happens to me is later on I’ll notice a bug, and realize my code doesn’t work correctly. For example, the correct code in this case was:
'Let's check if we are going to update all the fields that must be updated...
If record.table.RequiredMustBeSuplied IsNot Nothing Then
For Each req In record.table.RequiredMustBeSuplied
If query.UpdateFields(req.Key).value Is Nothing Then
Throw New ArgumentNullException
End If
Next
End If
So, I was able to test for problems I know about (missing fields) but not a problem I don’t know about (the difference between dbnull and nothing). Is unit testing just not very good at finding these kinds of errors, or is there an approach someone could suggest?
3
Unit tests should be built based on requirements and constraints that you know about. They will only ever be as complete as your thought processes. The wonderful thing, however, is that when you encounter a bug that you had not foreseen or tested, you can create a new unit test that covers that case even before you implement the fix, and then you never have to worry about that bug again. (use TDD for the win)
1
Your specifications should cover conditions that is known in the system artifacts, such as schema and business rules. However, as many developers do, the jump into code without taking the time to study the database design or even the specific requirements. This makes constructing complete test cases error prone because the development activity becomes mingled with design activity. Usually programming dominates since it consumes most of the effort and time. My point is you can avoid many problems if you take the time to design and spec out the problem at hand before coding.