diff options
Diffstat (limited to 'junit4/doc/cookbook/cookbook.htm')
| -rw-r--r-- | junit4/doc/cookbook/cookbook.htm | 143 |
1 files changed, 143 insertions, 0 deletions
diff --git a/junit4/doc/cookbook/cookbook.htm b/junit4/doc/cookbook/cookbook.htm new file mode 100644 index 0000000..2cf8eec --- /dev/null +++ b/junit4/doc/cookbook/cookbook.htm @@ -0,0 +1,143 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> + <meta name="Author" content="Erich Gamma"> + <title>JUnit Cookbook</title> +</head> +<body> + +<h1> +<font color="#33FF33">J</font><font color="#CC0000">U</font>nit Cookbook</h1> + +<p> +Kent Beck, Erich Gamma</p> + +<hr WIDTH="100%"> +<br>Here is a short cookbook showing you the steps you can follow in writing +and organizing your own tests using JUnit. +<h2> +Simple Test Case</h2> +How do you write testing code? +<p>The simplest way is as an expression in a debugger. You can change debug +expressions without recompiling, and you can wait to decide what to write +until you have seen the running objects. You can also write test expressions +as statements which print to the standard output stream. Both styles of +tests are limited because they require human judgment to analyze their +results. Also, they don't compose nicely- you can only execute one debug +expression at a time and a program with too many print statements causes +the dreaded "Scroll Blindness". +<p>JUnit tests do not require human judgment to interpret, and it is easy +to run many of them at the same time. When you need to test something, +here is what you do: +<ol> +<li> +Annotate a method with @org.junit.Test + +<li> +When you want to check a value, import org.junit.Assert.* statically, call <tt>assertTrue</tt>() and pass a boolean +that is true if the test succeeds</li> +</ol> +For example, to test that the sum of two Moneys with the same currency +contains a value which is the sum of the values of the two Moneys, write: +<blockquote> +<pre><tt>@Test public void simpleAdd() { + Money m12CHF= new Money(12, "CHF"); + Money m14CHF= new Money(14, "CHF"); + Money expected= new Money(26, "CHF"); + Money result= m12CHF.add(m14CHF); + assertTrue(expected.equals(result)); +}</tt></pre> +</blockquote> +If you want to write a test similar to one you have already written, write +a Fixture instead. +<h2> +Fixture</h2> +What if you have two or more tests that operate on the same or similar +sets of objects? +<p>Tests need to run against the background of a known set of objects. +This set of objects is called a test fixture. When you are writing tests +you will often find that you spend more time writing the code to set up +the fixture than you do in actually testing values. +<p>To some extent, you can make writing the fixture code easier by paying +careful attention to the constructors you write. However, a much bigger +savings comes from sharing fixture code. Often, you will be able to use +the same fixture for several different tests. Each case will send slightly +different messages or parameters to the fixture and will check for different +results. +<p>When you have a common fixture, here is what you do: +<ol> + +<li> +Add a field for each part of the fixture</li> + +<li> +Annotate a method with @org.junit.Before +and initialize the variables in that method</li> + +<li> +Annotate a method with @org.junit.After +to release any permanent resources you allocated in setUp</li> +</ol> +For example, to write several test cases that want to work with different +combinations of 12 Swiss Francs, 14 Swiss Francs, and 28 US Dollars, first +create a fixture: +<pre><tt>public class MoneyTest { + private Money f12CHF; + private Money f14CHF; + private Money f28USD; + + @Before public void setUp() { + f12CHF= new Money(12, "CHF"); + f14CHF= new Money(14, "CHF"); + f28USD= new Money(28, "USD"); + } +}</tt></pre> +Once you have the Fixture in place, you can write as many Test Cases as +you'd like. Add as many test methods (annotated with @Test) as you'd like. +<h2>Running Tests</h2> +How do you run your tests and collect their results? +<p>Once you have tests, you'll want to run them. JUnit provides tools +to define the suite to be run and to display its results. To run tests and see the +results on the console, run this from a Java program: +<blockquote> +<pre> +org.junit.runner.JUnitCore.runClasses(TestClass1.class, ...); +</pre> +</blockquote> +or this from the command line, with both your test class and junit on the classpath: +<blockquote> +<pre> +java org.junit.runner.JUnitCore TestClass1.class [...other test classes...] +</pre> +</blockquote> + +You make your JUnit 4 test classes accessible to a TestRunner designed to work with earlier versions of JUnit, +declare a static method <i>suite</i> +that returns a test. +<blockquote> +<pre><tt>public static junit.framework.Test suite() { + return new JUnit4TestAdapter(Example.class); +}</tt></pre> +</blockquote> +<h2> +Expected Exceptions</h2> +How do you verify that code throws exceptions as expected? +<p>Verifying that code completes normally is only part of programming. Making sure the code +behaves as expected in exceptional situations is part of the craft of programming too. For example: +<blockquote> +<pre><tt>new ArrayList<Object>().get(0); +</tt></pre> +</blockquote> +This code should throw an IndexOutOfBoundsException. The @Test annotation has an optional parameter "expected" +that takes as values subclasses of Throwable. If we wanted to verify that ArrayList throws the correct exception, +we would write: +<blockquote> +<pre><tt>@Test(expected= IndexOutOfBoundsException.class) public void empty() { + new ArrayList<Object>().get(0); +}</tt></pre> +</blockquote> +<hr WIDTH="100%"> +</body> +</html> |