1

Unit testing has been widely lauded as an indispensable part of software development, and TDD has many proponents.

However, due to the combinatorial nature of various pieces of code, it can be difficult to know when you have enough coverage of even a single method.

Consider a method that checks for an intersection between two rectangles. These rectangles are defined with four float values, X, Y, Width, and Height and returns true if the rectangles intersect and false if they don't. Already I can think of quite a few test cases:

  • One where the rectangles intersect
  • One where the rectangles do not intersect
  • One where the rectangles are the same size and have the same position
  • One where one or both of the rectangles have zero width, height, or both
  • One where a rectangle has odd float values like Infinity or NaN
  • One where the right edge of the first rectangle has equal coordinates to the left edge of the second (repeat for every combination of edges)
  • One where one or both rectangle bounds all of 2D space...

...and so on, and so on. And that's just for one method.

How many of these test cases are valuable? Am I approaching unit testing the wrong way?

Celarix
  • 139
  • 6
  • 4.2 billion each – CodesInChaos Aug 26 '16 at 20:39
  • Actually, for this method, it's closer to 1.16*10^77. – Celarix Aug 26 '16 at 20:40
  • FWIW I routinely write *at least* half a dozen cases per method. – RubberDuck Aug 26 '16 at 20:44
  • @mcknz Ah, didn't see that one. I kept searching for "enough unit tests" and that wording never occurred to me. – Celarix Aug 26 '16 at 20:44
  • The linked question has a good answer about equivalence classes and boundaries. It would be ridiculous to test all 4.5E74 possible rectangle combinations (no negative lengths!). The hard problem is finding out what combinations are equivalent. Off the cuff, I see 10 general equivalence classes (separate, inside, overlapping on N edge, NE corner, E, SE, S, SW, W, NW) + boundary conditions, + about double the tests to check the relation is symmetric: `r1 overlaps r2 = r2 overlaps r1`. The good news is that you can use table-driven testing: for each case, the test logic stays the same. – amon Aug 27 '16 at 09:23

0 Answers0