The following is a guest post by Stephen Vance, author of the book “Quality Code: Software Testing Principles, Practices, and Patterns”, which includes worked examples with jQuery Timepicker Addon.

When I was nearing completion of my recently released book Quality Code: Software Testing Principles, Practices, and Patterns, I had a big empty space at the end that my editor and I had earmarked “Worked Examples.” I wanted the examples to be realistic but accessible with the additional constraint that I could address them sufficiently in a chapter each.

At first, I thought I would print the full code for the examples, but that seemed like it would be redundant and overwrought as the code would have to evolve in support of testability. Additionally, some of the technical reviewer feedback suggested that I hadn’t devoted sufficient attention to dynamic languages like JavaScript and Ruby given their strong presence in the current application development ecosystem.

I considered omitting worked examples entirely, but that would leave the book too theoretical in my mind despite the amount of code used to illustrate the testing techniques. I really wanted to ground the whole thing in some usefully applied examples. I settled on a TDD from-scratch Java project and a JavaScript “legacy rescue” project. An example I used for a conference presentation satisfied the Java project need. The micro-commit approach I used to supplement the presentation suggested how to address the risk of code bloat; the chapters would be the narrative of the testing effort with GitHub hash references to my repos.

We were using the jQuery Timepicker Addon where I was working at the time. If Trent will forgive this characterization, it was shockingly good for a project of its size with absolutely no tests, but we encountered a few bugs along the way. I could serve the book, my employer, and the community all at once.

As an open source project, I technically didn’t need permission to put it to this use, especially since I wasn’t planning to print the code itself. However, I knew that it might not be the kind of thing someone would like to be blindsided with. Out of professional courtesy, I crossed my fingers and reached out to Trent for his support.

Trent’s response was overwhelmingly enthusiastic. I was bowled over. I had expected anything from “How dare you!” to “Sure, why not?” but had only dreamed of the degree of support and acceptance Trent extended.

As Timepicker users, you saw the first fruits of this collaboration in the 1.4 release. Trent also took the opportunity to completely overhaul the build approach and to add in other quality practices like jshint. It happened quickly enough that I could reference his acceptance of the pull requests in the book.

I have continued to add tests, although I have slowed down. Wrapping up a book takes far more effort than I would have imagined, and once the writing is done, the promotional support only begins. However, I’m committed to bringing the rest under test and perhaps adding Istanbul into the build to empirically evaluate the coverage.

Once we have a bit more coverage, changes can be made with the safety net of tests and we can refactor to simplify with a high degree of assurance. I hope you see the results, and I’d love to see many of you help us carry this forward in your contributions.