If you need to write that many tests for such a simple algorithm, you're going to be spending all your time writing tests and your programs will never be finished.
There are many ways of simplifying this. For example:
"You need 3 test cases for one of the numbers being 0. You need 3 test cases for one of the numbers being a negative. ... You need your null case (where all the inputs are 0’s)."
Or, you could just factor out that input validation into a single function, is_valid_length(), that you call on each of the three inputs to make sure that it's greater than or equal to zero. Then, you'd just need to test that function once.
I think you've misunderstood the point. The challenge is that someone else has written the code, and you are being asked to produce cases to feed it to test that it gets the answers right. You're not being asked to write the code, or factor the code, or write a function, or anything else like that.
So under those conditions, where the code has been written and it's your job to test it, what is your list of test cases?
In either case, I think my main point is still true: if you need to have so many test cases for such a simple program, you'll never finish performing all the tests for a real-world program. If you're testing someone else's program, you'll need to pick a manageable number of test cases that have a high probability of finding the errors. How likely is it that the programmer who wrote this code tests side "a" for being less than or equal to zero, but only tests side "b" for equal to zero and doesn't test side "c" at all? As a tester, I'd assume that if the program catches bad input for one side, it would do so for all sides, and then move on to test other things.
I deduce that you've only worked with a limited type of programmer. I have, indeed, tested code written by people who did not do as you suggest. That being the case, I wrote code to produce all the test cases, including all the permutations of the elements. In this case I would produce three numbers in non-decreasing order, and then output all six permutations of them.
I write safety-critical software, and I test safety-critical software written by others. I fully expect all of these cases to be tested, including feeding the program with non-numeric values, negative values, junk, and floating point numbers that are equal under various levels of precision.
If you're not doing this, you're deliberately choosing to sacrifice the program's quality for your time and effort spent testing. That's a choice you can, or course, make, but you should be very clear to yourself, if not your users, that you're doing it.
5 comments
[ 3.3 ms ] story [ 20.2 ms ] threadThere are many ways of simplifying this. For example:
"You need 3 test cases for one of the numbers being 0. You need 3 test cases for one of the numbers being a negative. ... You need your null case (where all the inputs are 0’s)."
Or, you could just factor out that input validation into a single function, is_valid_length(), that you call on each of the three inputs to make sure that it's greater than or equal to zero. Then, you'd just need to test that function once.
So under those conditions, where the code has been written and it's your job to test it, what is your list of test cases?
I write safety-critical software, and I test safety-critical software written by others. I fully expect all of these cases to be tested, including feeding the program with non-numeric values, negative values, junk, and floating point numbers that are equal under various levels of precision.
If you're not doing this, you're deliberately choosing to sacrifice the program's quality for your time and effort spent testing. That's a choice you can, or course, make, but you should be very clear to yourself, if not your users, that you're doing it.
https://en.wikipedia.org/wiki/Abductive_reasoning