Difference between revisions of "Creating Unit Tests"

From LongJump Support Wiki
imported>Aeric
imported>Aeric
 
(5 intermediate revisions by the same user not shown)
Line 16: Line 16:
}
}
</syntaxhighlight>
</syntaxhighlight>
''See also:'' [[Code Sample:Test of Search using Java API]]


{{Tip|Give your test methods meaningful names that tell what the test was trying to do. That way, when you're reading a report that identifies a failure, the name will tell you a lot. For example: <tt>testTwoPlusTwoEqualsFour</tt>.}}
{{Tip|Give your test methods meaningful names that tell what the test was trying to do. That way, when you're reading a report that identifies a failure, the name will tell you a lot. For example: <tt>testTwoPlusTwoEqualsFour</tt>.}}
Line 28: Line 30:
:* If multiple assertions fail, all of the failure messages are reported.
:* If multiple assertions fail, all of the failure messages are reported.
:* If one or more assertions fail, and then an exception occurs, all of the messages are reported, along with the exception.
:* If one or more assertions fail, and then an exception occurs, all of the messages are reported, along with the exception.
:* The test method (<tt>testSomeBehavior</tt>, above) must be public. If it isn't, an <tt>IllegalAccessException</tt> occurs when the <tt>@TestMethod</tt> annotation causes the Unit Test Framework to attempt execution.
:* The <tt>RunTest.assertEquals()</tt> method takes Strings as arguments (and only Strings).
{{Important|<br>When running tests, the UI is never affected. So your tests always run to completion without pausing for user interactions, regardless of the code contained in the executed methods. These cases in particular are executed without having any visible effect in the UI:
:* <tt>Functions.showMessage</tt> - Ordinarily brings up a dialog.
:* <tt>setTargetPage</tt> in a controller - Ordinarily specifies the next page the user will see.
:* Any request sent from a controller - Ordinarily specifies the controller code or JSP page that will be visited next.}}

Latest revision as of 17:55, 10 August 2011

Any method in a Java class can be a test method, as long as it is tagged with the @TestMethod annotation. Within the test method, use assert statements like this one to compare expected results to actual results: RunTest.assertEquals(expected, actual).

Here's a template for a test method:

/**
 * javadoc comment
 */
@TestMethod
public void testSomeBehavior() throws Exception
{
    String expect = "It's working!";         
    String actual = someBehavior();          // Invoke the method you're testing

    RunTest.assertEquals(expect, actual);
}

See also: Code Sample:Test of Search using Java API

Thumbsup.gif

Tip: Give your test methods meaningful names that tell what the test was trying to do. That way, when you're reading a report that identifies a failure, the name will tell you a lot. For example: testTwoPlusTwoEqualsFour.

Considerations
  • A single test method can contain multiple assertions.
  • Each successful assertion adds to the success count and the count of total tests.
  • A test method may contain no assertions at all. In that case, it runs to completion, but the test is not counted as a success.
  • A test may fail either because an exception occurs, or because an assertion fails.
  • In either case, the message is recorded. (For an exception, a stack trace is also recorded.)
  • Whether an assertion succeeds or fails, the method continues running. It is only interrupted by an exception.
  • If multiple assertions fail, all of the failure messages are reported.
  • If one or more assertions fail, and then an exception occurs, all of the messages are reported, along with the exception.
  • The test method (testSomeBehavior, above) must be public. If it isn't, an IllegalAccessException occurs when the @TestMethod annotation causes the Unit Test Framework to attempt execution.
  • The RunTest.assertEquals() method takes Strings as arguments (and only Strings).

Warn.png

Important:
When running tests, the UI is never affected. So your tests always run to completion without pausing for user interactions, regardless of the code contained in the executed methods. These cases in particular are executed without having any visible effect in the UI:

  • Functions.showMessage - Ordinarily brings up a dialog.
  • setTargetPage in a controller - Ordinarily specifies the next page the user will see.
  • Any request sent from a controller - Ordinarily specifies the controller code or JSP page that will be visited next.