13.07.2015 Views

Java™ Application Development on Linux - Dator

Java™ Application Development on Linux - Dator

Java™ Application Development on Linux - Dator

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

13.5 Writing Test Cases305Table 13.1 JUnit NamingClassMethodIn your original codeMyClassmyMethodIn your test caseMyClassTesttestMyMethodprepend the word “test” to the method name, and capitalize the now-no-l<strong>on</strong>gerfirstletter. Again, JUnit will use this naming c<strong>on</strong>venti<strong>on</strong>, al<strong>on</strong>g withintrospecti<strong>on</strong>, to automatically derive the test names from the actual methodnames (more <strong>on</strong> that later, too). The naming c<strong>on</strong>venti<strong>on</strong>s we’ve seen so far aresummarized in Table 13.1.Let’s take a quick look at the code. We import the framework for JUnittest cases, so that the compiler can resolve the names that deal with JUnit stuff.The TestCase class that we extend is part of that JUnit stuff. It’s an abstractclass that defines much of what we use for testing. We just fill in what we need.The TestCase class defines a method called setUp(). The setUp()method is called not just <strong>on</strong>ce, but before every test method is called. That wayyou can initialize variables and get into a known state before each test. Sinceit’s already defined in the TestCase class, we can override it (as in our example)to do what we want, or we can not include it in our class and get the defaultbehavior from TestCase (which is to do nothing).There is also a method named tearDown() which you can override if youneed to close things up at the end of a test case (e.g., close a database c<strong>on</strong>necti<strong>on</strong>).As with setUp(), its default behavior, as defined in TestCase, is to d<strong>on</strong>othing.The test case itself—the method where we will exercise our class—is calledtestCreateSub (since we want to test our createSub() method). Inside sucha method (and we could have more than <strong>on</strong>e) we write code which uses theobjects in our applicati<strong>on</strong>. Then at various junctures in the code we make asserti<strong>on</strong>sabout the state of things—for example, this variable should be n<strong>on</strong>-null,or this expressi<strong>on</strong> should have this particular value.Those asserti<strong>on</strong>s are, to our way of thinking, the tests. We’re testing to seeif the subaccount was created, or if the main account did, indeed, use up all ofits dollars in allocati<strong>on</strong> to the subaccounts. But they are not what is called testsby JUnit. Rather, each individual method in a test class is c<strong>on</strong>sidered a singletest. Such test methods are, typically, a collecti<strong>on</strong> of asserti<strong>on</strong>s surrounding theuse of a single (applicati<strong>on</strong>) method. So in our example, the method

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!