I wrote this little library recently to help generate some random dates. I made seven different commits to the project. I want to discuss what I did in each of them and the process to get from concept to completion.
In the first I knocked out a basic concept with a few tests, to show it probably worked. It had one extension method, one helper class, and two tests. In the second commit I added another extension method with two more tests. In the third commit I added a third extension method and three more tests. This is all normal stuff, the fourth commit is where the interesting stuff starts.
In the fourth commit I refactored the before and after methods to reduce the duplication between them. That’s the obvious part that most people would do. I also refactored the tests that were generating a bunch of random dates to use a common helper method. This is the part that most people miss in Red-Green-Refactor – they refactor the business code but skip the test code.
The fifth commit refactored to allow chaining multiple conditions together. I put in an implicit conversion from the builder to DateTime. I was using the builder pattern, but for whatever reason I didn’t call it a builder at the time. So, I changed it to call it a builder in the sixth commit along with updating it to allow me to generate multiple dates in the same range with one builder. Previously, the builder would only generate one date so the implicit conversion worked reasonably.
In the seventh commit I added overloads to the various extension methods for DateTime? as opposed to just DateTime. It was a little enhancement but it made it much nicer in some situations by pushing a bunch of null checking into the library itself.
There’s nothing revolutionary in either the software or the process but often times when talking about writing software, we talk in terms of fully formed libraries springing forth from the mind and not about the arduous process that you go through to get there.