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”.
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.
