What if you had a test case that looked like this? (Assuming a shape-drawing application such as Microsoft Visio…)
Point rectangleStart = DataManager.ScenePointProvider.GetNextValue();
Point rectangleEnd = DataManager.ScenePointProvider.GetNextValue();
Point circleCenter = DataManager.ScenePointProvider.GetNextValue();
Point circleRadius = DataManager.DoubleProvider.GetNextValue();
Logical.Fill.Color = DataManager.FullSpectrumColorProvider.GetNextValue();
Logical.Stroke.Color = DataManager.FullSpectrumColorProvider.GetNextValue();
Note that this test case:
- Says nothing about how its actions are carried out., Simply running this test case a number of times could cause the full set of possibilities to be executed. Further, if this test case is run alongside many other tests that also have nothing to say about how their actions are carried out each action would be executed sufficient numbers of times to allow each different execution method to be used multiple times.
- Contains no verification. It will not need to change to make the verification more complete or if the expected results of any of its actions change.
- Contains no references to any UI. It will not need to change regardless of how drastically the UI changes.
- Will only need to change if the functionality it is testing changes.
- Is very simple.
- Is focused on actions a user might take – it looks quite similar to the steps in a help topic, in fact.
- Writing it tests the spec.
- Could be written before the code it exercises exists.
- Could just “light up” once the code it exercises does exist.
Writing one test that stands in for several similar tests, writing that test early in the feature development process rather than late, and modifying that test only when the feature undergoes semantic changes: this is our vision for changing the way we test. Now let me explain the technology we are building to help us reach that vision.