Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>1) It's best to keep your tests small and focused. That way, when a test fails, it's clear why the test failed. This usually results in a single assertion per test, but not always. </p> <p>However, instead of hand-coding a test for each individual "invalid scenario", you might want to take a look at JUnit 4.4 Theories (see the <a href="http://junit.sourceforge.net/doc/ReleaseNotes4.4.html#theories" rel="nofollow noreferrer">JUnit 4.4 release notes</a> and <a href="http://www.brettdaniel.com/archives/2009/09/10/004350/" rel="nofollow noreferrer">this blog post</a>), or the JUnit <a href="http://kentbeck.github.com/junit/javadoc/4.8.1/org/junit/runners/Parameterized.html" rel="nofollow noreferrer">Parameterized</a> test runner. </p> <p>Parametrized tests and Theories are perfect for "calculation" methods like this one. In addition, to keep things organized, I might make two test classes, one for "good" inputs, and one for "bad" inputs.</p> <p>2) You only need to include the test cases that you think are most likely to expose any bugs in your code, not all possible combinations of all inputs (that would be impossible as WizardOfOdds points out in his comments). The three sets that you proposed are good ones, but I probably wouldn't test more than those three. Using theories or parametrized tests, however, would allow you to add even more scenarios.</p> <p>3) There are many benefits to writing unit tests, not just the one you mention. Some other benefits include:</p> <ul> <li>Confidence in your code - You have a high decree of certainty that your code is correct.</li> <li>Confidence to Refactor - you can refactor your code and know that if you break something, your tests will tell you.</li> <li>Regressions - You will know right away if a change in one part of the system breaks this particular method unintentionally.</li> <li>Completeness - The tests forced you to think about the possible inputs your method can receive, and how the method should respond.</li> </ul> <p>5) It sounds like you did a good job with coming up with possible test scenarios. I think you got all the important ones.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload