I interview a lot of software engineers at various points in their career; everything from junior developers fresh from University through to Principal Engineers who are masters of their craft.
One of the questions I often ask early on in the interview is this:
Imagine a software project that has a dedicated QA team who are perfect and have unlimited resources to check the product is correct. In this scenario, why should the business spend money on programmers writing unit tests?
This question is quite open-ended, mixes business concerns with pure engineering concerns and provides a guage of where someone is in how they approach issues. Invariably I end up learning something new myself when I ask this question!
A junior developer might get bogged down in the relationship between QA (Quality) and Unit Testing. Usually they really struggle because the question seemingly presents a conflict. Why should we test units if the whole is tested pefectly by a QA team? The fact that two forms of testing are presented sort of throws the person off. Sometimes i’ll get an “introduction chapter” to Unit Testing recited from memory or something similar. Usually describing “good” and “bad” unit tests is clunky, but we get there in the end.
Mid-level developers, usually with 5 or so years industry experience in a good engineering team take a solid stab at this. They’ll try and make arguments about “development speed” or “not having to wait until QA get the product to check it is right …” or something along those lines. Their gut sense is that unit testing and QA serve different purposes but they can’t really articulate it clearly.
Senior/Lead developers will state (correctly) that the QA team is mostly irrelevant to the question. Unit testing ensures unit (function, method, …) correctness as the developer understands their code unit, and for the benefit of other developers… whereas the passing or failing of these tests says nothing about the product meeting a given specification. Secondarily the senior will state that ensuring unit correctness is about stability, entropy and risk in a changing codebase. We might then have a discussion about technical debt balancing in tests or what makes a good/bad test or how TDD, BDD and other unit/non-unit testing approaches benefit the team. How nuanced these discussions are is telling.
One time a senior said something like “It really doesn’t matter how we engineer the product providing QA say it is perfect and we built it on-time and within budget” which was a bold evasion.
The Principal Engineer or architect will go straight for the science angle and frame it in a strong business context. Quite often they’ll avoid answering the question directly, but instead ask how we can “measure the cost/benefit” of the testing effort or question if “unit tests” can be thought of as one thing, or if we need to classify and explore why we test and ensure that the team understand the goals of testing. That’s just one example, but the common theme is: Questioning the question and keeping a strong business framing. When pushed the Principal tends to easily and eloquently fall-back to the senior/lead answer. One of the best answers I had to this question was “I’d ask the lead developer this question, they know their project, team and engineering best”. Smooth.
Open ended questions like these tell you a massive amount about an engineer. Two or three of them, picked wisely, give you more information than any technical test or asking them to write a unit test. I’m not sure Unit Testing is anyone’s favourite topic … and that’s why hearing answers to this question are so interesting!