Is a Driver’s License a Unit Test?

Is it appropriate to call a driver’s license a unit test? Would that be consistent with unit testing best practices? That was part of the discussion that erupted on our internal Yammer network after someone posted a link to coding by numbers. I argued that a driver’s license was not properly a unit test but an acceptance test of an incoming delivery. When you read the following, bear in mind that software development is a design activity. The context here is a company that needs help to design a solution for transporting people “from A to B”. This was the argument I made against saying that it is best practice to call a driver’s license a unit test in accordance with unit testing best practice.

System Boundary

The driver is a unit in the final system just as the car is. But when we deliver our “A-B transportation solultion” to the customer we do not provide drivers and we do not provide cars and we certainly do not provide customers. All those things, the customer must provide for themselves. Just as e.g. software developers do not provide operating systems, server hardware or end users to their customers. Or perhaps they do, if they are system integrators, but that would be another team anyway…

We might provide them with a specification, e.g. “your drivers should have valid drivers licences” – the other firm doing IT solutions would specify “your servers should run Windows 95 or better”.

Rapid Prototyping

In our design work, we will do an analysis of getting from A to B and we will start with a rapid agile prototype. After the first day of development we will have come up with a simple solution: ask the customer to walk from A to B When we put this through our CI system we will get a pass on the acceptance criteria, e.g. the customer – in this case some of our testers – (eventually) arrives as B. The outcome of the testing will cause some problems and we will go back to designing new tests.

  • The customer should have a smooth experience.
  • The customer should be able to sleep during the experience.
  • The transport should not take more than 25 minutes.

Exploring the Design Space by Refactoring

After a few more iterations where we re-factor our solution going through skate boards (no sleep possible), rickshaws (too slow), buses (too expensive, which leads to a new test case) etc we finally settle on a design with a chauffeured car. After testing different options we come to the conclusion that the driver is a highly variable component in terms of the “smooth experience”.

NT2673 : Rickshaw, Surgeon's Hall by Richard Webb
Rickshaw, Surgeon’s Hall
  © Copyright Richard Webb and
licensed for reuse under this Creative Commons Licence.

After our tester / driver is put in prison for driving withour a license – as we use CI, he was driving back and forth between A and B and people reported it as sucpicious to the police – we decide that we need to start sourcing drivers from another team.

Acceptance Testing Drivers

It is at this point that we add an *acceptance* criteria to our process, that all deliveries of drivers should be tested for their driving skills including showing a driving skills certificate. But while this might be done in our CI environment, we ask all new drivers to show their license to Hudson and then drive from A to B, it is not necessarily a unit test.

Unit Testing Drivers

If on the other hand, we decide that we should develop drivers ourselves. We would then proceed with some GA where the final test would be a drivers licence. In this case, I suppose we can call the license a unit test.

About Greger Wikstrand

Greger Wikstrand, Ph.D. M.Sc. is a TOGAF 9 certified enterprise architect with an interest in e-heatlh, m-health and all things agile as well as processes, methods and tools. Greger Wikstrand works as a consultant at Capgemini where he alternates between enterprise agile coaching, problem solving and designing large scale e-health services ...

Leave a Reply