Freigeben über


So What Should A Test Case Look Like?

What if you had a test case that looked like this? (Assuming a shape-drawing application such as Microsoft Visio...)

Logical.Projects.CreateNewProject();

Point rectangleStart = DataManager.ScenePointProvider.GetNextValue();
Point rectangleEnd = DataManager.ScenePointProvider.GetNextValue();
Logical.SceneElements.CreateRectangle(rectangleStart, rectangleEnd);

Point circleCenter = DataManager.ScenePointProvider.GetNextValue();
Point circleRadius = DataManager.DoubleProvider.GetNextValue();
Logical.SceneElements.CreateCircle(circleCenter, circleRadius);
Logical.SceneElements.SelectAll();

Logical.Fill.Color = DataManager.FullSpectrumColorProvider.GetNextValue();
Logical.Stroke.Color = DataManager.FullSpectrumColorProvider.GetNextValue();

Logical.SceneElements.Copy();
Logical.SceneElements.Paste();

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.

Comments

  • Anonymous
    May 20, 2005
    "Now let me explain the technology we are building to help us reach that vision."

    The Friday cliff hanger! :D
  • Anonymous
    May 21, 2005
    How is this test confirming for expected results? What if the rectangle isn't drawn?
    What if the app blows up, where do you test for unexpected failures?
  • Anonymous
    May 23, 2005
    The attributes that you mention are worthy, but shouldn't the list contain something about the risk that you're trying to test for, or the theory of error that might be at work?

    I mean: this test could identify a memory leak (especially if run a sufficient number of times); it could run through big sets of values; it could trigger a crash. But suppose that the user that you're simulating tried to create a rectangle, and then changed her mind and deleted it. Could this test make sure that the SceneElements object can handle the deletion properly, free the memory correctly, display the data in an appropriate way on display resolutions of various sizes? Maybe not--and that would be okay. I see to some degree what the test is supposed to DO. I find it harder to see what the test is supposed to TEST.

    Cheers,

    ---Michael B.
  • Anonymous
    May 25, 2005
    The comment has been removed
  • Anonymous
    May 25, 2005
    The comment has been removed
  • Anonymous
    May 25, 2005
    Visual Studio Team System

    Yesterday marked the one-year anniversary of the public announcement of...
  • Anonymous
    July 20, 2005
    In many of my posts I have alluded to the automation stack my team is building, but I have not provided...
  • Anonymous
    August 03, 2005
    In many of my posts I have alluded to the automation stack my team is building, but I have not provided...