Unit testing involves testing software at a component level to ensure that each element is functioning correctly. This differs from system testing where we determine whether the complete system is working as expected.
Our test framework is a simple FileMaker database. We have a record for each test we perform. The attached sample file shows how it all works. Conditional formatting highlights passed tests in green and the failed ones in red. I can’t take credit for coming up with this approach to the problem, it was shown in Steve Lane’s excellent Pause On Error session on Unit Testing.
How can you write a test that demonstrates correctly functionality? If you can’t answer that question while coding, then you need to ask yourself if you fully understand the requirement. Consequently a developer needs to think about how they will prove that the software works as expected. You will sometimes find that a custom function may not behave exactly as you thought.
The sample file demonstrates this in the two custom functions I’ve used as examples. They appear to work, but contain bugs that are not immediately obvious. The NumRange custom function doesn’t work as expected if the first number in the range is larger than the second. Likewise the explodedKey function doesn’t handle the user entering spaces with no other characters. Had these custom functions been used in a solution, they might have introduced bugs in the larger system.
Here’s the sample file:
Keeping the same tests through different versions of a custom function to permit regression testing. This ensures our revisions haven’t introduced new issues. Next time I’ll talk about how we can perform automated testing on FileMaker scripts.