One of the ways programmers make sure that their code works correctly is unit testing, which consists of running a small but self-sufficient piece of the code – a “unit” – for predetermined input values and comparing the output with the expected result. A good test suite (in theory) contains every corner case imaginable, ensuring that every nook and cranny of the software works in all those cases as it should, e.g. a function that adds two numbers should be tested for positive inputs, negative inputs, zero inputs, invalid inputs, missing inputs, too large inputs, too small inputs, unparsable inputs, and of course all of these for each of the two numbers to be added. This results in a huge number of tests even for relatively simple tasks.
The good news being that when you have a solid test for one case, writing additional tests is a matter of copy/paste and adapt to the corner case at hand.
my guess is the public method (actual code) relies on many private methods / nested or API calls / clever or complex logic etc. that looks compact in that method but requires tons of tests to account for all the behaviors
Been there, done that!
For those asking for an explanation: You sometimes end up writing a pair of production code/unit tests at the ratio show in this comic. It can literally be so that a function with only 5-6 lines would command writing 10-15 tests to cover all eventualities. At least, if you strive for 100% code coverage.
The Jenkins 
haha it’s so funny that i dont get it! (no offense hobson)
LikeLike
I feel like I get this but I feel like I don’t at the same time. Someone explain.
LikeLike
One of the ways programmers make sure that their code works correctly is unit testing, which consists of running a small but self-sufficient piece of the code – a “unit” – for predetermined input values and comparing the output with the expected result. A good test suite (in theory) contains every corner case imaginable, ensuring that every nook and cranny of the software works in all those cases as it should, e.g. a function that adds two numbers should be tested for positive inputs, negative inputs, zero inputs, invalid inputs, missing inputs, too large inputs, too small inputs, unparsable inputs, and of course all of these for each of the two numbers to be added. This results in a huge number of tests even for relatively simple tasks.
LikeLiked by 1 person
The good news being that when you have a solid test for one case, writing additional tests is a matter of copy/paste and adapt to the corner case at hand.
LikeLike
my guess is the public method (actual code) relies on many private methods / nested or API calls / clever or complex logic etc. that looks compact in that method but requires tons of tests to account for all the behaviors
LikeLike
means before target
LikeLike
Been there, done that!
For those asking for an explanation: You sometimes end up writing a pair of production code/unit tests at the ratio show in this comic. It can literally be so that a function with only 5-6 lines would command writing 10-15 tests to cover all eventualities. At least, if you strive for 100% code coverage.
LikeLike
Aren’t writing unit tests just a way of passing the day anyways. Unimaginable scenarios vs actual work where you have to try?
LikeLike
Looks about right. And kind of gets confirmed by the other comments…
LikeLike
lol this is totally cs51
LikeLiked by 1 person
guilty
LikeLike
hah I’ve been trying out unity as a game designer, and this is relatable
LikeLike
Effort(code) <> Value(tests)
(Except when it isn’t)
LikeLike
In a startup, the two labels get swapped.
LikeLike