# How many tests cases should there be for a method? [duplicate]

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?

• 4.2 billion each Commented Aug 26, 2016 at 20:39
• Actually, for this method, it's closer to 1.16*10^77. Commented Aug 26, 2016 at 20:40
• FWIW I routinely write at least half a dozen cases per method. Commented Aug 26, 2016 at 20:44
• @mcknz Ah, didn't see that one. I kept searching for "enough unit tests" and that wording never occurred to me. Commented Aug 26, 2016 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
Commented Aug 27, 2016 at 9:23