27 July 2016

Unit Test Benefits, Goals and Stories

I recently came across an old entry on a Blog that outlined the stories that a consultant was using in introducing Unit Testing concepts and practices to a group of developers.

What a great idea! They are a concise list of driving principles, guiding his activities. They could be easily turned into some measurable benchmarks, milestones that indicate how far the team has come and how much more work the consultant still has.

I am envious. I began doing something similar - introducing Unit Testing to a group of developers - a couple years ago. I became the team's Unit Test Evangelist, championing the practice.

I had some benefits of unit testing that I wanted them to grasp and run with. But I did not take the time at the outset to clarify to myself or articulate to the team's management, exactly what we hoped to achieve.

And of course without knowing what you want to achieve, it becomes harder to know if you succeeded. How will you know you are there when you don't have a clear idea of where you are going?

13 July 2016

TinT: Controlling Application Licenses in Unit Tests

Testing in the Trenches (TinT) is an occasional series recounting some of the situations I encountered and advice I gave real people and real teams on real projects to help them buy into and improve at applying the concepts of Unit Testing. Any identifying data has been changed to protect them. 

Not so very long ago, I worked with a software team whose application had some core functionality that the clients would purchase and install on their own machines (we did not host the system). This core functionality could then be expanded through about a dozen separate "Licenses" that the clients could purchase in whatever combination suited their needs. If the client wanted a web interface to the core desktop system, they could purchase one or more of the web-functionality licenses. Or if they needed more powerful tools for the financial processing side of the core application, they could buy the license that would allow access to those expanded features.

The state of the Licenses for any given installation was accessible to the code through public static methods. So for the imaginary MoneyPlus license, the code could check if the client held that license or not through a call such as:
if ( App.isMoneyPlusLicensed() )

There were no setters. At system launch, a process would do its secret work, using database settings, registry key lookups, calls to our own server or other secret acts to determine exactly what licenses the client had purchased, and would set the private license state flags accordingly.

License-setting was deeply buried in the core system and by design almost inaccessible, partly out of concerns for security and sales, partly out of concern (paranoia?) that clients might find a way to hack around and fake a license without paying.

7 July 2016

Shout-out for Good Customer Service: Abstrakti

Let me give a shout-out to Abstrakti Software for a job well done and excellent customer service.

My small team recently completed a project to move all of our development work from Visual Source Safe to Git source control management. Our code base was very large, with hundreds of thousands of source files across dozens of VSS projects spanning more than 17 years of history.

Preserving the VSS History was one of the project's top priorities, and for that we looked into a handful of tools that were designed for just that purpose.