So I’ve been meaning to make a fix in one of my projects for a while, and I haven’t touched the code in over a year, so of course I have to go back and really get back up to speed with the code. The change was for the Datavalve project and it was to include support for passing in collections and using
in SQL Statements, so now you can use something like :
provider.addRestriction("item.statusCode in (:param)", stateCodeList);
This will cause the list of codes to be expanded into an
in SQL statement including checking to exclude null items, and as usual, the restriction is not included if the code list is null or contains only null items.
So I have two problems, the first is getting back up to speed on my code, figuring out where the make the change, and making it. The second is making sure my code changes don’t break anything thats currently working.
For the first problem, I decide to create the unit tests first so I can verify that the change does as expected. Obviously, the tests fail initially, but by looking at the code executed by the tests, I can start to pick out places where I need to start looking to add the new code. After all, tests measure the correctness of the state after the code has been executed. What better place to start looking than seeing what code the test executes. After finding the method that I need to change, I make my code changes and run my tests. All my original tests pass with flying colors, but my new test fails. I take a peek and sure enough I left off the last line of code to add the built object to a list. I put it in, and I have all my tests up and running.
All in all, I’ve made a large change to some sizable (12K+ LOC) code that I haven’t seen in over a year, verified that the change works and that it hasn’t impacted any other code. Not bad for an hour.