Testing 1, 2, 3…
Recently, I’ve been working on a project that will ultimately require new users of the system to create their accounts with stronger passwords than the application has typically allowed. Existing users will be required to update their accounts with stricter passwords. The software is a distributed web application, and the code that I am working is a the application layer.
I’ve used a couple of design patterns to essentially build a framework that allows us to setup a password object and add and remove policies to it at runtime via XML flags. Policies are nothing more than rules that will evaluate the password against a single requirement, such as its length or whether or not it contains a specified number of digits and/or symbols. For every policy that the password is evaluated against, the framework will generate a set of error messages as well as a password strength rating and will return them once the rating process has completed.
Ultimately, this will all be bound to the front-end when the overall project is completed; however, for now, there’s no UI against which to test the framework’s performance. Since testing is arguably one of the most important phases of software development and since there’s no true UI to provide any level of feedback from this framework, I chose to take a true test-driven development approach to the password and its policies.
Write Test Cases First
Because we designed the software upfront, we new how the system should behave before we actually began building it. This made it relatively easy to write test cases first - we new what our inputs were going to be and we new exactly what outputs to expect for each case. After writing these cases, I found myself to be more conscientious of the code I was writing for the actual system.
Although it’s wrong, it’s not uncommon for developers to first build their application and then right the test cases (numerous articles are available online about this). This is incorrect for a number reasons primarily because you’re basically writing tests for a system you’ve already built - in the same way that writing code after the test cases made me more aware of what I was writing, writing your test cases after building the components will likely result in writing cases that fit the existing system. This completely misses the mark on the purpose of Test Driven Development. Writing test cases to fit the software is backwards - write your software to fit your test cases.
How long did it take?
This took a little bit longer to do for several reasons. First off, writing a test suite to cover branches, statements, outputs, etc. of your system adds to the amount of time to complete the project (or phase of the project). Couple that with updating various components and then developing new test cases for those changes, you’ve got a pretty full plate of things to maintain. Ultimately, it may result in a slightly longer period of time to complete, but if this is taken to account in project planning it shouldn’t be that big of a deal. Additionally, you’re only increasing the quality of the software, so I’d argue that it’s worth it more often than not.
Combinations and Permutations of Policies
This was the fun part. Initially, we started off with a small set of policies; however, as the project matured and we gathered more input, we had to create additional policies. This resulting in us testing possible error messages as well as the various strength ratings for each arrangement of the policies. It’s really not that big of a deal if you’ve got a couple of people working on the project, but it’s easy to see how fast something can increase in complexity by simply introducing one or two more components.
Overall Impressions
Building this framework using Test-Driven Development was great. It prevented the project and it’s various combinations of outputs from getting away from us very early in development. It also resulted in a great feedback of a system that doesn’t have an interface with which to interact. Finally, it generated a strong sense of software quality once the system was developed and all of the test cases passed.
Maybe I’ll revisit this project to show off the interface once we’ve finished it, but that’s not really something I’m planning to focus on showcasing. We’ll see.
That’s it for now,
Tom