After weeks of development a change in a fundamental aspect of the domain has surfaced. To outsiders (read: the business) this change may seem insignificant, but to people who write lines of code, it is understandably a relatively big issue.
Basically, we have a model that has several major components related to one another. The relationships in this model were described early as only existing from a start date, to an end date. These dates were literally java.util.Dates… each with a month a day and a year. Each relationship could start and end and then restart and end again based on (again) Dates.
After some peculiar discoveries made upon seeing some of the underlying legacy data, we determined that the real domain rule was that there weren’t really requirements for effective/expiration ‘Dates’, but more effective/expiration Year Months.
After much ado, we got reassurance from the subject matter experts that yearmonth-to-yearmonth was the real unit of measure for the effective ranges rather than date-to-date. I knew this would simplify the model a lot. There was some irritation at the late surfacing of this concept (since it was questioned a lot earlier), but we got through it. Now we had to make the changes. Since I was the primary author of the domain model classes I made the changes there. I spent about 3 hours and really felt the joy of having the unit tests to validate the changes. Over and over I’d change a test or two, run them to failure, change the code to accomodate the new concept of yearmonth, run the tests and see the wonderful green bar. Once I committed the new model to CVS, it was time to reconcile it with the 5 applications that use it. One by one we tackled them. A change here, a change there and the same comforting green bar.
I dont want to imply that it was easy. We had some heated discussions about the ramifications of the new time concept and some people downright objected to the meaning and differences between ‘isAfter’, ‘isBefore’, ‘isInRange’, etc. but we worked through those issues and we have a better model, and 5 better applications because of it. Not only that, but I think some of the team members had the light bulb turn on seeing the relative ease with which we accepted such a major change and successfully accomodated it in a very short period of time. They’re starting to understand the true meaning of ‘agile’ as it pertains to software development… this is a good thing.
mikewitters.com 
Sounds like it went great. Not sure how people can object to the meaning of isBefore et al, but whatever.
I love seeing concrete examples of how UT helps in the ‘real world’