5

The only unit tests tactic I'm familiar with is comparing against golden data _ a predefined set of input data for which output is known (preferably including corner cases).

I cannot think of any other reasonable way of unit testing. Trying to unit test using arbitrary input data is (at least) as difficult as writing the application itself.

Are there any effective tactics for unit testing other than golden data testing?

Note: By saying arbitrary data I mean any syntactically valid input which a method can accept (including logically invalid inputs).

superM
  • 7,363
  • 4
  • 29
  • 38
  • 1
    What is "golden" data in your world view? – Kilian Foth Jan 30 '14 at 10:48
  • Can you clarify what you mean by "arbitrary input data"? – Andy Hunt Jan 30 '14 at 10:49
  • 1
    In order to test on arbitrary data you need a second implmentation of your software. If a third party implementation exists and is trusted, you can use that, otherwise there's zero point. Part of testing is making sure your assumptions were correct, so if you're just reimplementing those same assumptions in testing then you're missing a pretty big chunk. – Phoshi Jan 30 '14 at 10:50

2 Answers2

6

You might want to have a look at equivalence partitioning vs boundary value analysis. Testing against "golden data" (boundary value analysis) is indeed the best compromise, giving good enough confidence that everything is covered in most cases.

Community
  • 1
guillaume31
  • 8,358
  • 22
  • 33
  • Thanks @guillaume31. I'm somewhat familiar with the topic and I've come to the same conclusion. – superM Jan 30 '14 at 11:01
4

The tactics for unit testing vary depending on the "test unit" being tested in that test.

If the test unit is an implementation of a function that performs a calculation based on a combination of inputs and its current state, then a good unit test would be to put that object into the defined state, and then call the function and verify its output is the golden data

If the test unit is responsible for deciding which object from a list it should return, then a good unit test would be to force populate that list with its (mock?) objects, and then verify that the expected object instance was returned.

Some units being tested do not match the "golden value" style of testing.

Consider, a function which is responsible for sequencing a series of calls to other objects. In this case, you are likely to create a mock/fake objects to receive these calls, and then instead of comparing golden values, you are checking that these objects were called with appropriate parameters.

Some unit tests are written to verify the absence of behaviour

Consider how you would validate that a function that needed to make a function call if certain conditions were met. Its as important to validate that this call does not occur if the conditions are not met, as it is to verify its called when they do meet.

Finally, sometimes verifying that a function does not generate exceptions across a wide range of inputs can be important.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36