Theory: Drivers, the MUT & IV&V
This lesson closes Lecture 7 with two ideas that look small but come back later. The first is the driver, the little program that lets you test one method on its own; it returns in Lecture 8 together with its partner, the stub. The second is IV&V, the most independent form of testing there is, and the most expensive.
The Driver and the MUT
Imagine you want to test a car engine before the car exists. You cannot turn a key or press an accelerator, because there is no dashboard and no pedal yet. So engineers bolt the engine to a test stand: a rig that feeds it fuel, turns it on, sets the throttle and reads the gauges.
Testing one method alone works the same way. Lecture 2 called this controllability (see 2.2): to test a method you must be able to give it exactly the inputs you choose. The code you want to test is the MUT (method under test). The test stand is the driver:
A driver is a small test program that calls the MUT with test inputs and collects the result, so the tester can compare it with the expected output.
Diagram loads as you scroll.
Synchronous vs. asynchronous
The driver usually waits for the MUT to finish and return its value before it continues. This is called synchronous communication. The difference is easiest to see in everyday life:
| Synchronous | Asynchronous |
|---|
| Everyday picture | A phone call: you stay on the line and wait for the answer. | A chat message: you send it, do other things, and the reply arrives later. |
| In code | The caller blocks until the called method returns. | The caller continues; the result arrives later (callback, message, event). |
| For a driver | The usual case: call the MUT, wait, compare the result. | Harder to test: the driver must wait for, or be notified of, a result that comes later. |
Coming next: the stub
A driver sits above the code under test and calls it. In Lecture 8 (8.2) you meet its partner, the stub, which sits below the code under test and replaces a module that the code calls but that does not exist yet. Remember the pair now: a driver calls the code under test; a stub is called by it.
IV&V: Independent Verification and Validation
IV&V (independent verification and validation) means verification and validation carried out by an independent company, completely separate from the developers. It is the far end of the independence scale from Lecture 5, where you met third-party testing (see 5.1).
Think of a restaurant. The chef tastes every dish, and the restaurant may even have its own quality manager. A food-safety inspector from the government is something else: an outsider who has no reason to be kind to the kitchen, who checks everything from scratch, and whose visit costs the restaurant real time and money.
Diagram loads as you scroll.
- Where it is required: in safety-critical software, where a failure can kill people: defense, aviation, medical devices, nuclear systems.
- Strength: no bias. The outside company did not write the software and has no stake in it passing, so IV&V is very strong and effective.
- Weakness: very expensive. The outside company must learn the software from zero, and the developers must spend time supporting it.
Exam radar: if a question asks for the main weakness of IV&V (or of third-party testing in general), the answer the professor wants is cost.
Worked Examples
Exercise 1
What is a MUT, and what is a driver? Why do we need a driver to test a single method?
Show solution ↓Hide solution ↑
Solution
The MUT is the method under test, the code we want to test. A driver is a small test program that calls the MUT with test inputs and collects its result.
We need a driver because a single method cannot run on its own: something has to call it. When we test it in isolation, the real callers may not exist yet or may not let us choose the inputs. The driver gives us controllability: we decide exactly which inputs the MUT receives, and we can observe what it returns.
Exercise 2
Explain the difference between synchronous and asynchronous communication using an everyday example. Which one does a driver normally use?
Show solution ↓Hide solution ↑
Solution
Synchronous communication is like a phone call: you ask a question and stay on the line until you get the answer. Asynchronous communication is like a chat message: you send it, go on with other things, and the reply comes later.
A driver normally uses synchronous communication: it calls the MUT and waits for the return value before it continues, then compares that value with the expected result.
Exercise 3
A driver and a stub are both pieces of fake code built for testing. What is the decisive difference between them?
Show solution ↓Hide solution ↑
Solution
The difference is the direction of the call:
- A driver sits above the code under test and calls it with test inputs.
- A stub sits below the code under test and is called by it, replacing a lower module that is not available yet.
So: driver = fake caller above; stub = fake module below. (Stubs are covered fully in 8.2.)
Exercise 4
What is IV&V? Give one domain where it is required and explain why.
Show solution ↓Hide solution ↑
Solution
IV&V (independent verification and validation) is verification and validation performed by an independent company, completely separate from the developers.
It is required for safety-critical software, for example aviation (also defense, medical devices, nuclear systems), because a failure there can kill people. In such domains the cost of an undetected bug is so high that the strongest, unbiased form of testing is worth paying for.
Exercise 5
Give the main strength and the main weakness of IV&V. Why does the weakness arise?
Show solution ↓Hide solution ↑
Solution
- Main strength: no bias. The independent company did not write the software and has no interest in seeing it pass, so it tests it critically and effectively.
- Main weakness: cost. IV&V is very expensive.
The cost arises because the outside company starts with no knowledge of the software. It must learn the requirements, the design and the code from zero before it can test well, and the developers must spend time explaining and supporting it.