Building on the Damages Billing System
The beginning of this week was spent finalizing the tests around saving the billing information from being sent from the tablet into our database. This was a relatively short process because I had done the majority of the work last week and just had some small updates to make. Once I was done here, I had to start thinking about how I was going to add to the Damages Billing system, namely to expose a public endpoint I could send this billing data to, but from my application (because the Damages Billing system is a completely separate application, similar to the housing location system I’ve used in the past).
We started by isolating what function is being used to save all the damage information when a user does it through the actual webpage workflow. This took a bit to figure out for a couple reasons – 1. I had no idea how the application itself worked (as in what the actual workflow even was) and 2. The codebase for this system is pretty horrendous (think 3000 line C# files built in webforms with MVC2). On top of this the ORM the application uses has little to no documentation and has pretty much been abandoned now. There was a lot that I had to learn to get to a functional place in this project.
Once we figured out what code was saving all the data (damaged items to be billed, what kind of item the damaged item is, who is being billed for the item, how severe the damages are, what the cost will be) we copied the code into a repository so we could write tests around it to figure out exactly how it works. There were a couple of motivations for this. We want to be able to reuse this logic both in the place where it is currently being used and then in the endpoint we will eventually develop, but we also want to have a bunch of tests around how it works so we can more safely refactor and improve the code itself.
Writing the tests was a lot of work because I had to essentially completely learn how this portion of the application worked – after a lot of trial and error over a couple of days I had a bunch of working tests, including several new repositories to wrap the gross SubSonic logic (whoever thought having a static database context should seriously rethink their motivations for this ORM), as well as a database clean up helper and test object assertion helper.
By the end of the week I had a good amount of integration tests complete with a good base for future additions if they’re required. I tried to test all the standard workflow scenarios as well as as many edge case scenarios that we could come up with. This has probably been one of the most difficult tasks I’ve had to work through since I’ve worked in this office. I was basically thrown into a completely new environment using technologies I had no experience with, but I just applied the same practices I use on my regular projects and slowly built up something that was reasonable and made sense. It was slow going at first, but things got a lot easier as the week progressed.
Now that I had my tests in place, I first wanted to refactor the code for the tests themselves and make adding future tests easier and more straightforward. Once I have these refactors in place I will be able to start doing refactoring on the code I’ve spent the last couple days testing. I spent the last half of Friday working on refactoring the tests with a few things left to work out on Monday when I left the office.