The 27 test example doesn't take advantage of the independence provided by OR. One doesn't need to test every combination of pairs, as there is no conditional logic between them. Consider:
A = B, C = D, E = F : DoAnother() A < B, C < D, E < F : DoAnother() A > B, C < D, E < F : DoOneThing() A < B, C > D, E < F : DoOneThing() A < B, C < D, E > F : DoOneThing()
That's five tests, but it tests equivalence, greater than, and less than for each pair.
This provides the same confidence as the 27 test example, with half the tests of the decreased encapsulation example.
And if one of the 'OR's changed to an 'XOR', the tests would still pass, but the behaviour would change.
Taking advantage of the logical independence of OR produces a gap due to its reliance on the use of OR.
Mind you whilst the level confidence may not be the same as with the 27 test example, the drop may not be particularly significant, thus illustrating the original point I suppose.
yes... the format of this blog isn't as code friendly as an 8.5x11 page. I've been playing with the code format. Small font, or break the lines... sometimes with resulting oddness. Comments on that appreciated.
It is also interesting to look at the NPath complexity metric for a function or method as it gives you a pretty good estimate of how many tests you need.
Great example! A suggestion if I may?
OdpovedaťOdstrániťThe 27 test example doesn't take advantage of the independence provided by OR. One doesn't need to test every combination of pairs, as there is no conditional logic between them. Consider:
A = B, C = D, E = F : DoAnother()
A < B, C < D, E < F : DoAnother()
A > B, C < D, E < F : DoOneThing()
A < B, C > D, E < F : DoOneThing()
A < B, C < D, E > F : DoOneThing()
That's five tests, but it tests equivalence, greater than, and less than for each pair.
This provides the same confidence as the 27 test example, with half the tests of the decreased encapsulation example.
-Ben
And if one of the 'OR's changed to an 'XOR', the tests would still pass, but the behaviour would change.
OdpovedaťOdstrániťTaking advantage of the logical independence of OR produces a gap due to its reliance on the use of OR.
Mind you whilst the level confidence may not be the same as with the 27 test example, the drop may not be particularly significant, thus illustrating the original point I suppose.
You mention, "Limit the exposure by controlling scope appropriately, as we did in the Java code above.".
OdpovedaťOdstrániťI'm not a java guy but it appears to me that you've made the extracted functions private and not testable from outside this class.
What am I missing?
Gary, the first comment under the first extracted conditional indicates the visibility which is package.
OdpovedaťOdstrániťThanks Tim.
OdpovedaťOdstrániťJust not paying close enough attention.
yes... the format of this blog isn't as code friendly as an 8.5x11 page. I've been playing with the code format. Small font, or break the lines... sometimes with resulting oddness. Comments on that appreciated.
OdpovedaťOdstrániťIt is also interesting to look at the NPath complexity metric for a function or method as it gives you a pretty good estimate of how many tests you need.
OdpovedaťOdstrániťGood example of equivalence class partioning.
OdpovedaťOdstrániť