High-Grade Testing Using JUnit

Transcription

1 High-Grade Testig Usig JUit 6 IN THIS CHAPTER Test, code, refactor, desig. Repeat. Aoymous Overview Test-drive developmet. Testig frameworks. JUit, Cactus, StrutsTestCase, HttpUit, HtmlUit, JWebUit, SwigUit. These days there is almost as much to be leared about testig APIs as the libraries with which you are writig your code. JUit, the most popular of the curret testig frameworks, was created by Erich Gamma ad Ket Beck. You may remember Erich Gamma as oe of the authors of the groudbreakig book Desig Patters. Ket Beck, i additio to various cotributios i software aalysis ad desig, is resposible i part for a small earthquake called Extreme Programmig (sometimes called Agile Programmig so as ot to upset the fait of heart).. Overview 113. The JUit Framework 114. Creatig a Test Case 116. Ruig the Test 120. Creatig ad Ruig a Test Suite 122. Custom JUit Lauch Cofiguratios 126. Extesios to JUit 127 Documetatio, source code, ad biaries for JUit ca be foud at which will poit you to SourceForge ( where the latest versio ca be foud. However, you are oe of the select few who have dowloaded a tool that already has the latest versio of the most popular testig framework o the face of the plaet. The real issue is why you should use it. Eclipse makes the creatio ad use of tests almost trivial (almost because you still have to decide what to test ad how to test it). Havig JUit built i is ot uique to Eclipse as a Java IDE, but as a additioal piece to a already feature-rich IDE, it makes the decisio to go with Eclipse all the more easy.

2 114 CHAPTER 6 High-Grade Testig Usig JUit I am ot goig to sped time tryig to covice you that writig tests is good for you, your programs, ad your paycheck. What I will say is that without tests to prove your code works, you do t kow for sure that it does work. Do tests prove that your code works i every istace? Of course ot. Your users will be certai to remid you of that. What tests will do for you is guaratee that the situatios you ve plaed for work, the situatios that do t work fail gracefully, ad bugs that have bee squashed stay that way. Let s take a look at how you ca do all this usig Eclipse. The JUit Framework The JUit framework is made of a umber of classes that take care of the itty-gritty details of ruig your tests, as well as ruig a GUI to visually display which of your tests have passed ad which have failed. From your perspective, you eed to lear oe class: TestCase. Oce you become comfortable with TestCase the you may, o occasio, use TestSuite. The process of usig JUit ca be summed up as follows: 1. Write a test class that subclasses TestCase. It should ot be able to compile because you have ot yet writte the class to be tested. Your first test has just failed. 2. Write the class that eeds to be tested. Your first test ow passes. 3. Add to the test class a test of fuctioality you have ot yet writte i the other class. As your secod test, this also fails. 4. Write the smallest amout of fuctioality i the other class. Your secod test ow passes. 5. Test aother bit of oexistet fuctioality. This test fails. 6. Add the missig fuctioality. The test ow passes. By ow you should see a patter emergig. Write the test, which fails, ad the write the fuctioality for which the test is checkig, which causes the test to pass. You start with the simplest fuctioality ad work your way up. As the fuctioality gets more complex, you kow that prior fuctioality cotiues to work. If prior fuctioality stops workig, you kow it right away ad you ca fix it before the complexity grows out of had. Writig JUit tests i Eclipse is oly margially differet. I order to take advatage of the JUit Wizard, the class to be tested must exist. I Eclipse s case, the previous list would look like this: 1. Create a empty class to be tested. 2. Create a subclass of TestCase to test the other class. 3. Write a test of simple fuctioality of the other class. The test fails. 4. Write the simplest piece of fuctioality for the other class. The test should ow pass.

3 115 The JUit Framework 5. Write aother test ad watch it fail. 6. Add the fuctioality that will cause the test to pass. Perform steps 5 ad 6 util it is time to go home, util you hit a milestoe date, or util you have to deliver your code. If you used use cases to drive your schedule ad test-drive developmet to prove that the use cases pass the good scearios ad kow how to behave i the bad scearios, you wi. TestCase Whe you write a test case, you subclass juit.framework.testcase. I the same way that a servlet subclasses HttpServlet so that the servlet egie kows how to maage its life cycle, you are resposible for subclassig TestCase so the JUit framework ca walk your test object through its life cycle. The TestCase API icludes assert methods that you will use to cofirm the validity of results retured by the object uder testig. Let s discuss what happes whe a test case rus withi Eclipse. The JUit framework starts up, loads the test class selected o the workbech (your test class does ot eed mai()), creates as may copies of your test case as there are methods that start with the word test (for example, testfidcustomer()), ad begis to ru the test objects oe at a time. Before the test method is ru, a iitializatio method called setup() is called to give you the opportuity to create whatever objects you eed to make your test work. Whe your test method completes, either with a success or failure, a cleaup method called teardow() is called so your code ca safely dispose of used resources. The Graularity of Tests A questio that always comes up i discussios about tests ad testig frameworks is, how may tests (meaig assertios) should you put i a test method? The quick aswer would be to put oe assertio per test method because it gives JUit the opportuity to ru all your tests rather tha just the oes that passed prior to the oe that failed. However, the umber of tests ca get rather high, i which case you would have a immese umber of test methods, which would be hard to maitai (the secod argumet agaist tests). The loger aswer is, group associated tests together as log as they make sese. Start with oe test method per method beig tested. As you fid that the methods are gettig too log, break them up ito fuctioal test areas. I other words, use refactorig as a way of cotrollig the ievitable oslaught of success. TestSuite A suite of tests ca be ru by creatig a subclass of juit.framework.testsuite. Withi this class, you would list the various subclasses of TestCase that you would like JUit to ru by overridig suite(). Whe you create a test suite usig Eclipse, the code geerator uses code markers so that it ca regeerate the suite as ofte as you like. After you complete the example, you will get a chace to create, ad re-create, a test suite.

4 116 CHAPTER 6 High-Grade Testig Usig JUit FIGURE 6.1 JUit s TestRuer displayig the red bar, sigalig it is ot time to go home yet. TestRuer: The JUit GUI So how does JUit ru withi Eclipse? Do you simply select a test ad ru it like a Java applicatio? Whe JUit, or oe of its variats, rus withi Eclipse, it opes TestRuer, the GUI used by JUit to display the results of completed tests (see Figure 6.1). The most visible part of TestRuer is the colored bar that rus below the title bar. You will lear to questio a red bar whe you expected a test to pass ad a gree bar whe you expected a test to fail. Below the colored bar are three status values: how may tests of the available umber of tests have ru, how may errors (o-juit exceptios) occurred, ad how may failures (assertio failures) occurred. Below these couters are two tabs: The Failures tab lists the methods that failed, ad the Hierarchy tab lists all the methods with either a red X (error), a grey X (failure), or a gree check (success). Below the method list is the output of the curretly selected method. If the method succeeds, there should be o output. If the result bar is red, expect to fid output. The title bar of TestRuer has five coveiece buttos: Next or Previous Failed Test Either of these buttos will take you directly to the method that ecoutered a failure or error. Stop JUit Test Ru I case the test class has ecoutered a ifiite loop or has simply decided to hag, you ca kill JUit from here. Reru Last Test The same as pressig Ctrl+F11, except it oly rus the last JUit test, ot the last class that was ru. Scroll Lock Used to keep the selected test ad its output i syc. Creatig a Test Case I order for you to get a good feel for how to use JUit, let s create a class that simply prits out a greetig. The greetig is chageable, as is the ame of the perso beig greeted.

5 117 Creatig a Test Case Create a Class Start Eclipse ad create a Java project called Greeter. Due to the way the JUit Wizard works, you eed to create the class to be tested first. Create a ew class called Greeter i package example (you ca create the package at the same time you are creatig the class). The class should be quite empty after the code geerator is doe creatig it. Create a Test Case Let s look at creatig a JUit test. With the Greeter class selected i the Package Explorer, press Ctrl+N (or you ca right-click the Greeter class ad select New, Other). Whe the New dialog appears, select Java, JUit, JUit Test Case (see Figure 6.2). Click Next. Because this is the first time you are creatig a JUit test, the JUit Wizard will ask if you would like it to add the JUit JAR file to your class path. Click Yes to go to the JUit Test Case page. If you selected the Greeter class before you pressed Ctrl+N, the JUit Test Case page should be almost completely filled i. If the page does ot appear to be populated, click Cacel ad start agai. FIGURE 6.2 The New dialog with the JUit test case selected. This page lists all the iformatio eeded to geerate the class: The ame of the source folder to which the class should be writte. The package ito which the test class will go. You could put the test class ito a differet package, but covetioally the test classes live i the same package as the class they are testig. This gives the test class access to package/protected methods that may eed to be tested. The ame of the class to be tested. The ame of the test class. The wizard uses the covetio of appedig the word Test to the ed of ay test classes. Other IDEs use the word Test as a prefix for the JUit classes they geerate. If you come up with aother covetio, just be cosistet. The super class of the test class. This will almost always be juit.framework.testcase, uless you come up with aother class that you would prefer to exted. Be aware, though: if the class does ot ultimately exted TestCase, it will ot work withi the JUit framework.

6 118 CHAPTER 6 High-Grade Testig Usig JUit The oly missig iformatio eeded is which of the lifecycle methods you wat the class to iclude. Check setup() ad teardow() ad the click Fiish (see Figure 6.3). Whe the GreeterTest class opes i the Java editor, go to setup() ad remove the call to super.setup(). I its place create a Greeter object ad store it i a istace field called _greeter: protected void setup() throws Exceptio { _greeter = ew Greeter(); FIGURE 6.3 The JUit Test Case page with the two mai life cycle methods selected. A light bulb ad red X appear i the left margi o the lie where _greeter is declared. Click oce o the light bulb ad, whe the cotet assist widow opes, double-click Create Field _greeter. Save the file oce the istace field is created. The code i setup() affords you the opportuity to sigle-source the creatio of objects used through the test class. Because all your tests will eed a Greeter object, setup() is a ideal place to create it. Next, empty out the teardow() method ad set _greeter to ull: protected void teardow() throws Exceptio { _greeter = ull; Now, o matter what happes, you will always have a good object to work with before the test starts, ad the object will always be released to garbage collectio whe the test completes. This may ot seem like a big deal for a sigle test, but you ca safely assume that you will have dozes, hudreds, maybe eve thousads of tests ruig as your code developmet progresses. Oe of the thigs we wat the Greeter class to do is to retur a greetig for display. A strig retured as a result for display should ot be ull. (Yes, I kow there are plety of reasos why you might wat a ull retured from a method, but ot i this case.) Our first test is ow defied: a call to the method that returs the greetig should ot retur ull. Above setup(), defie the method testgreetig() as follows: public void testgreetig() {

7 119 Creatig a Test Case Withi testgreetig(), make a call to the Greeter method getgreetig(): public void testgreetig() { Strig actual = _greeter.getgreetig(); Yes, it is true that there is o method i the Greeter class called getgreetig(). Remember step 3 of the developmet of JUit tests? Your first test just failed. I order to make it succeed, you eed to add the method to the Greeter class. Eclipse makes this a trivial task. Just sigle-click the light bulb ad double-click the suggested fix i the cotet assist widow: Create method getgreetig() i Greeter.java The Greeter class comes forward, showig you the ew method that has just bee added. Save the Greeter.java. Retur to the GreeterTest editor widow ad save the file. The light bulb is goe, ad our test-by-implicatio test is ow successful. Because your first real test is to make sure you do t get a ull from the call to getgreetig(), you eed to take the result of the call ad compare it agaist a expected result. By extedig TestCase, you have a extesive selectio of methods to check the result of a call ad either do othig if the result was as expected or complai if the result was ivalid. TestCase exteds the Assert class, which has the followig assertio methods: assertequals() asserttrue() assertfalse() assertnotnull() assertnull() assertnotsame() assertsame() fail() All the assertxxx() methods will throw a AssertioFailedError if the value they are passed is false. The fail() method throws a AssertioFailedError as soo as it is called. Each oe gives you the choice of usig its default error message or oe you supply. For the test i testgreetig(), you could make a call to assertequals() ad compare the result to ull, but the assertnotnull() method will work much better:

8 120 CHAPTER 6 High-Grade Testig Usig JUit public void testgreetig() { Strig actual = _greeter.getgreetig(); assertnotnull( getgreetig() retured ull., actual); Ruig the Test Save your files ad make sure that GreeterTest is the active editor. From the mai meu, select Ru, Ru As, JUit Test. You already kow that the getgreetig() method is goig to retur a ull, so ruig TestRuer should give you a red bar (see Figure 6.4). If a gree bar appears, make sure you are callig the proper assert method ad that you are passig i the result of the call to getgreetig(). Let s fix getgreetig() so it does ot retur a ull: public Strig getgreetig() { retur ; Simply returig a empty strig should cause the test to be successful, ad pressig Ctrl+F11, which rus the last thig you executed, causes TestRuer to retur a gree bar. Success! SHOP TALK White Box Testig Versus Black Box Testig A black box test is a test ru o code without you kowig its iteral makeup. A white box test is a test where you kow exactly what is goig o i the code. JUit tests are usually white box tests, but you could also write black box tests agaist third-party vedor libraries. Whe I first started writig tests, I foud it a little discocertig to kow that I was writig tests to prove that code would behave i the fashio I had writte it. Checkig whether a method returs (or does t retur) a expected result seemed trivial, especially whe I kew what the code was doig. Why should I check, for example, that a method does ot retur a ull whe I kow it will ever retur a ull? There was o code aywhere (i the code I had writte) that could possibly retur a ull. I foud out the reaso as soo as I used someoe else s code i my algorithm. If the set of acceptable values is kow, a test eeds to be writte to check that the result does ot fall outside of this set or, if the value does fall outside the acceptable set, that the bad value is retured uder kow coditios.

9 121 Ruig the Test FIGURE 6.4 The TestRuer GUI with the expected red bar ad the message passed i as the first argumet to assertnotnull(). If this were a chapter o writig tests i a icremetal fashio, here are the ext tests you would try to write: 1. Test for a default greetig. 2. Test the ability to chage the curret greetig with a ull (throw a exceptio), a blak strig (throw a exceptio), ad a oblak strig. 3. Test whether the greetig ca be reset to the default. 4. Test for a default greetig that ca be persoalized. 5. Test the ability to chage the persoalizable greetig with a ull (throw a exceptio), a blak strig (throw a exceptio), ad a oblak strig. 6. Test whether the persoalizable greetig ca be reset to the default. The umber of thigs that ca be implemeted i the Greeter class is ot isigificat, but you ca check them reliably by addig slightly more complex tests i each iteratio. But I digress. Whe you discover a test that fails ad the code has reached a complexity level where simply eye-ballig it does ot suggest where the problem may be, you eed to debug the code through your test. Debuggig a JUit test is the same as debuggig ay other Java code: set a breakpoit i the test code or i the class beig tested ad from the mai meu select Ru, Debug As, JUit Test. The Debug perspective opes ad displays TestRuer at the bottom of the scree after the first full ru, with the debug views ad editor above it (see Figure 6.5).

10 122 CHAPTER 6 High-Grade Testig Usig JUit FIGURE 6.5 The Debug perspective with the JUit TestRuer displayig the methods to be ru. Everythig discussed so far would give you the impressio that you ca oly ru tests at the object level. I fact, you ca select oe method for executio to the exclusio of all the other test methods. Select the method to be executed from the Package Explorer or the Outlie view, or double-click the method ame i the Java editor. From the mai meu, select Ru, Ru As, JUit Test. Oly the selected method will be ru withi JUit. Ufortuately, you ca oly select oe method at a time; this is ot a arbitrary selectio. Creatig ad Ruig a Test Suite As metioed before, a JUit test suite cotais oe or more tests that should be ru as a uit. TestSuite is a composite object that cotais Test objects (icludig other test suites) that are prepared to ru all or oe of their tests. Whe the JUit framework starts, it uses reflectio to make a call to the suite() method of the object created from the icomig class type. Because JUit uses reflectio, the oly thig the class has to defie to work withi the framework is suite(). The icomig class does ot have to be a type of Test. The suite() method must retur a object of type Test so that the framework ca begi ruig tests. The suite() method returs a Test object that cotais whatever test objects you decide. Iterally, JUit performs the same operatio, oly it creates eough objects of your test type to ru each idividual method.

11 123 Creatig ad Ruig a Test Suite To make this explaatio clearer, let s look at a class that defies suite() ad returs a TestSuite object composed of a combiatio of sigle-method tests ad multiple-method tests: package example; import juit.framework.test; import juit.framework.testsuite; public class AllTests { public static Test suite() { TestSuite suite = ew TestSuite( Test for example ); // Oly ru the amed methods. suite.addtest(ew TimeSeriesServiceTest( testgettimeseries )); suite.addtest(ew OTCQuoteServiceTest( testgetotcquote )); suite.addtest(ew QuoteServiceTest( testgetquote )); // Ru all of the tests cotaied withi each class. //$JUit-BEGIN$ suite.addtestsuite(otcquoteservicetest.class); suite.addtestsuite(quoteservicetest.class); suite.addtestsuite(timeseriesservicetest.class); //$JUit-END$ retur suite; The AllTests class has the followig features: It does ot exted ay JUit class. It declares a suite() method that will retur a object of type Test. Withi suite(), a TestSuite object is created. The TestSuite object has three method-specific tests added to it through calls to addtest(). Because method ames are beig passed ito the test class costructors, oly those tests will be ru. The TestSuite object has three test classes added to its iteral list through calls to addtestsuite(), ad all the tests withi each test class will be executed.

12 124 CHAPTER 6 High-Grade Testig Usig JUit If the three test classes metioed i the AllTests class have two test methods each, the call sequece might look somethig like this: I testgettimeseries(). I testgetotcquote(). I testgetquote(). I testgetotcquote(). I testgetotcquotename(). I testgetquote(). I testgetquotesymbol(). I testgettimeseries(). I testgettimeseriesfloat(). The three sigle tests were ru first. Next the test classes were called, i tur, ad all their tests were ru before movig o to the ext test object. All these methods have a System.out.pritl() lie, but ormally the tests are silet if they succeed. To geerate a class that creates a TestSuite object, you ope the New dialog ad select Java, JUit, TestSuite ad the click Next. The JUit Test Suite page will display the source folder i which the code will be geerated, the package to which the class will belog, ad the ame of the class, which defaults to AllTests (see Figure 6.6). I the list below the test suite ame are the various JUit tests the builder recogizes. You ca select zero or more JUit tests for iclusio i TestSuite. FIGURE 6.6 The JUit Test Suite page with all the available tests checked. Also for the purposes of the example, I have deleted the commets from the code that was geerated by the JUit Wizard. Let s look at what was created: package example; import juit.framework.test; import juit.framework.testsuite; public class AllTests { public static Test suite() { TestSuite suite = ew TestSuite( Test for example ); //$JUit-BEGIN$

13 125 Creatig ad Ruig a Test Suite suite.addtestsuite(otcquoteservicetest.class); suite.addtestsuite(quoteservicetest.class); suite.addtestsuite(timeseriesservicetest.class); //$JUit-END$ retur suite; The first lie i AllTests.suite() is the istatiatio of a TestSuite object. TestSuite, as a composite object, is the cotaier of the various tests you wat to ru. The ext lie is a code marker used by the JUit builder i case you decide to regeerate the suite. Aythig outside of the code markers will be saved, whereas aythig withi the markers will disappear whe you regeerate the code. The ext lie of code adds a class defiitio to the TestSuite object usig addtestsuite(). This has the effect of creatig a ew TestSuite object ad addig all the methods that start with test to the ew TestSuite object, which is the added to your topmost suite. At the ed of all this, suite() returs the TestSuite object. What happes as you add ad remove idividual tests i the course of developmet? Regeerate the test suite class. You ca do this i oe of two ways: Press Ctrl+N (which opes the New dialog), select Java, JUit, Test Suite, ad the click Next. The JUit Test Suite page will display a warig that suite() already exists ad that it will be replaced uless you give the test suite class a ew ame (see Figure 6.7). Right-click the test suite class i the Package Explorer ad select Recreate Test Suite from the pop-up meu. The Recreate Test Suite dialog will list the available JUit tests for you to choose from. Select the tests you wat to have appear i the code ad click OK (see Figure 6.8). FIGURE 6.7 The JUit Test Suite page displayig the warig about suite() beig replaced. Ruig the test suite is o differet from ruig a regular JUit test (you select Ru, Ru As, JUit Test). If you try to ru the test suite as a regular Java class, it will ot work (uless you add mai() ad a call to TestRuer). I have bee very careful ot to say that the JUit Wizard creates a TestSuite class. The wizard does ot. The wizard geerates a class that cotais the suite() method, which will istatiate a TestSuite object ad retur it to ay callers.

14 126 CHAPTER 6 High-Grade Testig Usig JUit I additio, the JUit Wizard oly creates test suites made up of complete tests. If you wat to have the suite() method call certai test methods, you have the task of addig by had the calls to addtest() i suite(). Custom JUit Lauch Cofiguratios FIGURE 6.8 The Recreate Test Suite dialog listig the available JUit tests that ca be added to suite(). By selectig to ru the JUit test (which is either a subclass of TestCase or a test suite) usig Ru, Ru As, JUit Test, you allow the Laucher to create a default lauch cofiguratio ad execute the TestRuer GUI usig this default cofiguratio. If you were to ope the Ru dialog (by selectig Ru, Ru), you would see i the Cofiguratios list to the left the JUit category with GreeterTest as a cofiguratio etry (you did ot get the opportuity to create all the classes for the test suite example, so there is o lauch cofiguratio for it). Ruig a JUit test with the default lauch cofiguratio will do the job for most rus; however, creatig a custom laucher lets you decide whether you wat to ru oe test or may (see Figure 6.9). FIGURE 6.9 The Ru dialog of the Eclipse Laucher.

15 127 Extesios to JUit The Laucher Ru dialog has the base fuctioality discussed i previous chapters (cofigurable ame, cofigurable eviromet variables, ad sharable lauch cofiguratios as well as the ability to create ew cofiguratios, pass argumets both to the VM ad the ruig class, select a JRE, ad have a custom source path). The Test tab allows you to do the followig: Ru a sigle test You ca use the Browse butto to select a ew project, or you ca use the Search butto to display the list of available tests. You ca oly select oe. Ru all the tests from either a project, a package, or a folder Selectig the radio butto for this choice eables the Select butto, which, whe clicked, displays a dialog listig the available projects, packages, ad folders (see Figure 6.10). FIGURE 6.10 The Folder Selectio dialog of the Eclipse Laucher Test tab. Fially, the check box labeled Keep JUit Ruig After a Test Ru Whe Debuggig is useful oly if you are usig a JDK that supports the hot-swappig of code. Whe you are debuggig a JUit test ad you modify ad recompile the code, the hot swap will oly work if you have checked the Keep JUit Ruig box. To create a ew JUit cofiguratio, remember to select either the JUit category i the Cofiguratios list or oe of the JUit cofiguratios ad the click New. Extesios to JUit Not to be outdoe i the ope-source marketplace for testig frameworks, a umber of additioal packages have emerged that allow testig of Java techologies that are ot easily tested due to their iclusio i applicatio frameworks. For example, servlets, JSPs, ad EJBs oly ru withi a cotaier framework that the average JUit test caot easily test agaist. Developers abhor a vacuum. Almost before ayoe realized how cool JUit really was, extesios were already beig writte to allow for the testig of cliet-side ad server-side Java compoets i their ative eviromet. Here are some examples: Cactus A server-side testig framework for the testig of servlets, EJBs, ad other server-side Java techologies. HttpUit/HtmlUit/jWebUit Various frameworks for testig Web applicatios. The best thig about testig at this level is that the tests are really user-level tests. Pick a use case ad write your HttpUit, HtmlUit, or jwebuit test as proof that the use-case sceario works based o how the user acts ad reacts to the system ad that the system behaves predictably whe the use-case failure scearios occur.

16 128 CHAPTER 6 High-Grade Testig Usig JUit JMXUit A testig framework for JMX Beas. StrutsTestCase A testig framework for Struts. VirtualMock A AOP-based framework that uses the cocept of mock objects, which allow for the testig of objects without cocer as to the objects the objects beig tested call. A mock object is a object that returs predictable values to the object uder test. For example, database fuctioality is always difficult to test due to the ecessary setup ivolved i makig the tests repeatable. If the objects to be tested call mock database objects, you ca test these objects based o what they believe they are receivig rather tha what they would actually receive. Please do ot take iclusio i this list as a edorsemet as to the usefuless of the these frameworks. Their usefuless will vary depedig o your eeds ad where the developers of the frameworks are with their projects. However, performig a quick search o SourceForge results i the followig available testig frameworks ad utilities: JFCUit, StrutsTestCase, jwebuit, JUitEE, Pouder, Artima Suite Ruer, Cricket Cage, JUitEJB, JXUit, GroboUtils, JUitDoclet, NoUit, AgileDox JUit-addos, Quilt, JUB, Hasel, ad JFuc. This is ot a complete list, ad I expect it to grow. Cactus has emerged as oe of the more popular server-side testig pieces for Java. It tests server-side compoets from the safety of a cliet-side positio. Usig a No-Plug-i-Based JUit Extesio As of the writig of this chapter, a Cactus plug-i for Eclipse has ot see the light of day (well, it did ad the it was pulled back ito the closet kickig ad screamig). However, all is ot lost. You ca still write Cactus tests with the existig JUit Wizard. A otrivial example will explai how to set up everythig eeded to make that happe. Let s begi by istallig Tomcat ad Cactus. Whe those two items are ready to go, you will write a sample servlet ad its test ad the display the results of the test. I order to ru a servlet, you eed a servlet egie. If you do t already have Tomcat, you ca dowload it from ad istall it i your favorite locatio (for example, c:\tools\jakarta-tomcat ). From the same Web page, you ca also dowload Cactus (scroll up to look for it ad istall Cactus ito your favorite locatio for example, c:\tools\jakarta-cactus ). Your versios will probably be ewer. At this stage, you have completed the most difficult part of this example: dowloadig ad istallig the latest versios of Tomcat, ad Cactus. Cactus eeds o cofiguratio, ad you will cofigure Eclipse to ru Tomcat from the Eclipse Laucher. I a more complete J2EE eviromet, such as MyEclipse from Geuitec, there would be editors, wizards, ad builders specific to servlets ad JSPs. However, due to the additio of Tomcat support i Eclipse 3.0, you ca develop basic J2EE applicatios by settig up the proper directory structure i your project ad creatig a valid web.xml file.

17 129 Extesios to JUit Create a servlet ad deploy it to Tomcat usig the followig steps: 1. Create a ew project by pressig Ctrl+N. Whe the New dialog opes, select Java Project ad the click Next. Eter the project ame CactusTest ad click Next. I the Java Settigs page o the Source tab, set the Default Output Folder to CactusTest/WEB- INF/classes. Click the Libraries tab, click Add Exteral JARs, ad avigate to <Tomcat Istall Directory>/commo/lib. Select servlet-api.jar ad click Ope. Click Fiish to close the New dialog. The use of the WEB-INF directory gives you the Web applicatio structure you will eed whe you deploy to Tomcat, ad servlet-api.jar gives you the J2EE symbols eeded to compile servlets. 2. Create a servlet class by pressig Ctrl+N. From withi the New dialog, select Java, Class ad the click Next. Eter example for Package, HelloWorldServlet for Name, ad javax.servlet.http.httpservlet for Superclass. Click Fiish. 3. HelloWorldServlet will ope i the Java editor. Right-click i the editor ad click Source, Override/Implemet Methods. Whe the Override/Implemet Methods dialog opes, check doget() ad click OK. Delete the TODO lie ad super.doget(arg0, arg1). Add code to get the PritWriter from the HttpServletRespose object ad write a message. If you do t add code to produce some output, the servlet will fail to ru: protected void doget(httpservletrequest arg0, HttpServletRespose arg1) throws ServletExceptio, IOExceptio { PritWriter out = arg1.getwriter(); out.prit( This is a message from the HelloWorldServlet! ); Fix ay compile errors by pressig Ctrl+Shift+O to add ay missig imports. Save the file. 4. Create a web.xml file by pressig Ctrl+N. From the New dialog, select Simple, File ad the click Next. Make sure the paret folder is CactusTest/WEB-INF ad eter web.xml as the fileame (see Figure 6.11). Click Fiish. 5. I the web.xml file, create a Web applicatio etry that maps your HelloWorldServlet to the servlet ame helloworld. This allows you to access the servlet usig the ame helloworld. Save the file: FIGURE 6.11 The New dialog preparig to create a empty web.xml file.

18 130 CHAPTER 6 High-Grade Testig Usig JUit <!DOCTYPE web-app PUBLIC -//Su Microsystems, Ic.//DTD Web Applicatio 2.3//EN > <web-app> <servlet> <servlet-ame>helloworld</servlet-ame> <servlet-class>example.helloworldservlet</servlet-class> </servlet> <servlet-mappig> <servlet-ame>helloworld</servlet-ame> <url-patter>/helloworld</url-patter> </servlet-mappig> </web-app> FIGURE 6.12 The Export dialog, set up to copy the project files ito the Tomcat webapps directory. 6. Deploy the CactusTest project to Tomcat. The simplest way to do that is to export CactusTest ito the Tomcat webapps directory. I the Package Explorer, right-click the CactusTest project ad select Export from the pop-up meu. Whe the Export dialog opes, select File System ad click Next. O the File System page, select the CactusTest project i the widow to the left ad ucheck the.classpath ad.project files i the widow to the right. Click the plus sig to the left of the CactusTest ode to reveal the WEB-INF, classes, ad src directories. Check oly the WEB-INF directory. This will export everythig uder WEB-INF, icludig classes ad web.xml. The To Directory field eeds to referece the Tomcat webapps directory. Click Browse ad avigate to your Tomcat istallatio directory. Whe you fid it, select it ad click New Folder. Eter the folder ame CactusTest, press Eter, ad click OK to see the export directory target (see Figure 6.12). If the To directory does ot display a path that icludes CactusTest, click Browse, avigate to it, ad click OK. Click Fiish to deploy your project to Tomcat.

19 131 Extesios to JUit FIGURE 6.13 variable set with the Tomcat home directory. The catalia_home Strig Substitutio Variable dialog opes, click Browse, avigate to the Tomcat istallatio directory, ad click OK to retur to the Edit Strig Substitutio Variable dialog (see Figure 6.13). Click OK to close the Edit Strig Substitutio Variable dialog ad the click OK to close the Prefereces dialog. 8. From the mai meu, select Ru, Ru. Whe the Ru dialog opes, select Tomcat Server from the Cofiguratios list ad the click New. For Name, eter CactusTest, ad for Web Applicatio Root, eter /CactusTest (see Figure 6.14). Click Ru. Whe the Ru dialog closes, the Cosole view will come forward ad begi to output Tomcat loggig statemets. You are ready to check your servlet whe the Cosole has a statemet similar to this: INFO: Server startup i 9494 ms 7. I order to start Tomcat from withi Eclipse, you eed to create a Tomcat lauch cofiguratio. Eclipse already defies a strig-substitutio variable called catalia_home, but it is ot assiged a default value. From the mai meu, select Widow, Prefereces ad Ru/Debug, Strig Substitutio. The Variable colum lists catalia_home with a empty Value. Select the catalia_home row ad click Edit. Whe the Edit FIGURE 6.14 The Ru dialog with a ew Tomcat Server cofiguratio for the CactusTest Web applicatio. 9. Ope a browser ad set the URL to You should see your message i the browser (see Figure 6.15).

20 132 CHAPTER 6 High-Grade Testig Usig JUit FIGURE 6.15 The HelloWorldServlet output displayed i a browser. At this poit, you ow have a workig servlet that i practice may or may ot have a JSP to which it is redirectig. Now let s take a look at what it would take to ru a test o it. The itetio of this part of the chapter is ot to explai the hows ad whys of Cactus, but to show you how you ca implemet Cactus tests eve without direct Cactus support withi Eclipse. However, i order to appreciate what eeds to be doe, you will eed a certai amout of Cactus backgroud. Cactus, as a server-side testig framework, has both a cliet-side ad a server-side compoet. The server-side piece rus o the same server as the servlet, ad the cliet-side compoet receives messages from the server-side piece via sockets. I order for that to work, you will eed to update the Web app web.xml file ad carry alog certai JAR files that must be deployed o the server with the servlet ad the servlet test code. Here s the short list of thigs that eed to be doe to write Cactus tests i Eclipse: 1. Copy a collectio of JAR files eeded by Cactus ito WEB-INF/lib. This is for the Cactus test that rus o the Web server. These will be deployed alog with the servlet to be tested. 2. Add a collectio of JAR files to the classpath of the project. This way, you ca ru the Cactus test as a cliet so that it ca coect to the server-side Cactus test. 3. Update web.xml to iclude the Cactus filter ad servlet mappigs. 4. Write a Cactus test either by extedig ServletTestCase or by istatiatig a ServletTestCase object withi a JUit test. If Tomcat is properly set up withi Eclipse, you ca ru the Cactus test as a stadaloe JUit test ad it will commuicate with the server-side code returig the results of the tests. Cactus ca be used to test servlets, JSPs, EJBs, ad ay server-side Java compoets. For this example, because you are goig to write a servlet test, you will ot look at some of the other test classes you could have exteded. The CactusTest project will cotai both the servlet to be tested ad the test code. Let s fill i the precedig steps. Before you create the test class, you eed to import the followig JAR files ito the WEB-INF/lib directory for use by the Cactus server-side piece (all the JAR files are from the Cactus istall directory):

21 133 Extesios to JUit aspectjrt jar cactus jar commos-loggig jar commos-httpcliet-2.0.jar juit jar Add these to your CactusTest project by right-clickig WEB-INF ad selectig Import from the pop-up meu. Because you wat to copy the JAR files ito the project, whe the Import dialog opes, from the Select page choose File System as the import type ad click Next. From the File System page of the Import dialog, click the top Browse butto to avigate to the lib directory of the Cactus istallatio (for example, C:\tools\jakarta-cactus \lib) ad select the lib ode from the tree view i the widow to the left. Whe you select the lib ode, the available JAR files i that directory will be listed i the widow to the right. Select the five JAR files listed previously (eve if the versio umbers are differet they should be higher [see Figure 6.16]). Chage the Ito Folder from CactusTest/WEB-INF to CactusTest/WEB-INF/lib FIGURE 6.16 The Import dialog listig the JAR files foud i the Cactus istallatio lib directory. ad click Fiish. Your WEB-INF directory ow has a lib directory, ad it cotais the Cactus JARs. These JAR files will be used by your test whe it rus o the server. The ext step is to add a collectio of JAR files eeded by Cactus oto the project classpath. Ope the project s Properties dialog by right-clickig the CactusTest project ame i the Package Explorer ad selectig Properties from the pop-up meu. Select Java Build Path from the list to the left ad the Libraries tab from the Java Build Path page to the right. Click Add Exteral JARs ad avigate to your Cactus istallatio lib directory (agai, for example, C:\tools\jakarta-cactus \lib). Holdig dow the Ctrl key, select the followig JAR files: aspectjrt jar cactus jar

22 134 CHAPTER 6 High-Grade Testig Usig JUit commos-httpcliet-2.0.jar commos-loggig jar juit jar Click Ope to select these five JAR files. They will be added to the Libraries tab s build path (see Figure 6.17). Click OK. FIGURE 6.17 The five JAR files eeded from the Cactus istallatio by the cliet-side Cactus test. The third step is to add the Cactus-specific filter ad servlet iformatio ito the Web applicatio web.xml file: <!DOCTYPE web-app PUBLIC -//Su Microsystems, Ic.//DTD Web Applicatio 2.3//EN > <web-app> <filter> <filter-ame>filterredirector</filter-ame> <filter-class>org.apache.cactus.server.filtertestredirector</filter-class> </filter> <filter-mappig> <filter-ame>filterredirector</filter-ame> <url-patter>/filterredirector</url-patter> </filter-mappig>

23 135 Extesios to JUit <servlet> <servlet-ame>helloworld</servlet-ame> <servlet-class>example.helloworldservlet</servlet-class> </servlet> <servlet> <servlet-ame>servletredirector</servlet-ame> <servlet-class>org.apache.cactus.server.servlettestredirector</servlet-class> </servlet> <servlet-mappig> <servlet-ame>servletredirector</servlet-ame> <url-patter>/helloworld/servletredirector</url-patter> </servlet-mappig> <servlet-mappig> <servlet-ame>helloworld</servlet-ame> <url-patter>/helloworld</url-patter> </servlet-mappig> </web-app> This web.xml file is the complete file you will use. It cotais both the HelloWorldServlet servlet mappig as well as the filter ad servlet iformatio eeded to call Cactus (the shaded code). The oly item of ote is the way the Cactus ServletRedirector servlet is defied: Because our HelloWorldServlet is mapped to the ame helloworld, the ServletRedirector must be defied relative to the servlet to be tested, so /helloworld is placed before ServletRedirector i the <url-patter> tag of the servlet mappig. FIGURE 6.18 The Superclass Selectio dialog displayig the Cactus ServletTestClass. After all that setup, it is time to create a Cactus test. Select HelloWorldServlet i the Package Explorer view. Create a class that exteds ServletTestCase by pressig Ctrl+N to ope the New dialog ad selectig Java, JUit, JUit Test Case. Click Next. I the JUit Test Case page, all the stadard iformatio should be filled i for you. The oe chage you eed to make is to chage the superclass to ServletTestCase. Click Browse, eter ServletTest i the topmost text field of the Superclass Selectio dialog, ad select ServletTestCase (see Figure 6.18). Click OK to close the Superclass Selectio dialog. Click Fiish o the New JUit Test Case page to close the dialog ad accept the class iformatio. The HelloWorldServletTest opes i the Java editor ad is quite empty.

24 136 CHAPTER 6 High-Grade Testig Usig JUit A stadard JUit class has a setup() method, a teardow() method, ad oe or more test methods that start with the word test. Cactus ca use the setup() ad teardow() methods, but it also adds the capability to add custom setup ad teardow methods per test. The custom setup ad teardow methods are called begi<ame of method beig tested>() ad ed<ame of method beig tested>(). The test method for the servlet is goig to test the doget() method, so you could create three methods: begidoget(), eddoget(), ad testdoget(). For this example, you will oly create the last two. To check whether the call to doget() streamed iformatio to the caller, you are goig to check the servlet output i eddoget(). For the purposes of this exercise, you are oly goig to look at callig doget(), but Cactus allows you to call ay method defied i the servlet. Two objects created by Cactus to predictably test servlets are WebRequest ad WebRespose. WebRequest represets a HTTP request message to the servlet, ad WebRespose represets the HTTP respose from the servlet. Whe eddoget() is called, its sigle argumet is goig to be a WebRespose object. You will use it to fid out what the servlet prited out, as show here: package example; import java.io.ioexceptio; import javax.servlet.servletexceptio; import org.apache.cactus.servlettestcase; import org.apache.cactus.webrespose; public class HelloWorldServletTest exteds ServletTestCase { public void testdoget() { HelloWorldServlet servlet = ew HelloWorldServlet(); try { servlet.doget(request, respose); catch (ServletExceptio e) { e.pritstacktrace(); catch (IOExceptio e) { e.pritstacktrace(); public void eddoget(webrespose respose) { Strig actual = respose.gettext();

25 137 Extesios to JUit Strig expected = This is a message from the HelloWorldServlet! ; assertnotnull(actual); assertequals(expected, actual); The testdoget() ad eddoget() methods are quite small. To test a servlet, Cactus asks that you istatiate your servlet i the test method as well as check its respose i the ed method. The code i testdoget() does the followig: Istatiates the servlet. Calls doget() ad passes i predefied request ad respose objects. The try/catch code is there as protectio i case the method call throws a exceptio. As you ll recall, the doget() method of HelloWorldServlet gets the PritWriter object ad the prits a greetig. The testdoget() method makes the call to doget(), ad the test method eddoget() gets the text from the respose object ad compares what it fids to what it was expectig. Your Web applicatio eeds to be deployed to Tomcat. Right-click the CactusTest project ad select Export from the pop-up meu. Select File System from the Select page ad click Next. Select ad ope the CactusTest ode ad ucheck classes ad src i the list to the left ad ucheck.classpath ad.project i the list to the right. Make sure To Directory is set to the Tomcat webapps/cactustest directory. Click Fiish. Whe the Questio dialog opes askig if you wat to overwrite existig files, click Yes To All. There is oly oe thig left to do before you ru the test: You eed to create a lauch cofiguratio to give the Cactus framework the URL to use i callig the servlet. Select HelloWorldServletTest i the Package Explorer ad select Ru, Ru from the mai meu. I the Ru dialog, select ay of the JUit tests or the JUit ode ad click New. A ew cofiguratio page appears with as much iformatio as the system could glea from the file you selected before opeig the dialog. The oly thig left for you to cofigure is the URL for Cactus to use i testig the servlet. Eve though you could pass Cactus the URL to use by settig up a cactus.properties file, you will istead put the URL i a eviromet variable that the JVM will place i the rutime eviromet. Click the Argumets tab ad eter the followig i the VM Argumets area (see Figure 6.19): -Dcactus.cotextURL= Click Apply ad the click Close to shut dow the Ru dialog. You re doe! Time to ru the test.

26 138 CHAPTER 6 High-Grade Testig Usig JUit FIGURE 6.19 The Ru dialog with the eviromet variable etry for cactus.cotexturl. If you have ot stopped Tomcat sice you last started it, go to the Cosole view ad click the red square butto located o its toolbar (it is the first butto o the left). The Cosole view title will display a message similar to the followig: Cosole (<termiated> CactusTest [TomcatServer]... Restart Tomcat from withi Eclipse by opeig the Lauch Cofiguratio dialog (select Ru, Ru ad the select Tomcat Server, CactusTest). Click Ru. The Cosole view should have fresh output from the Tomcat server. Whe the Cosole states that the server has started, you are ready to ru the Cactus test usig JUit. Check that the servlet is available by opeig a browser ad goig to You should see the same page as before with your welcome message displayed. FIGURE 6.20 The JUit TestRuer displayig the gree bar of success for the Cactus servlet test. Select HelloWorldServletTest i the Package Explorer. From the mai meu select Ru, Ru As, JUit Test. The Laucher will use the lauch cofiguratio you just created ad will start the JUit TestRuer with HelloWorldServletTest as its oly test class. If all goes well, the TestRuer GUI will ope ad display the gree bar of success (see Figure 6.20). Click the Hierarchy tab to see that testdoget() was ru ad that it succeeded.

27 139 Extesios to JUit If you already had the TestRuer GUI ope, it may ot come to the frot if the test passes, so click the JUit tab to see it. The test that just ra wet through the followig steps, assumig Tomcat is ruig ad the servlet is available (this is a very abbreviated versio of the actual process): The cliet code, HelloWorldServletTest, ra ad performed stadard JUit iitializatio. The Cactus framework looked for the begidoget() method. Because you did ot write begidoget(), this did ot do aythig. Cactus opeed a coectio to the ServletRedirector ruig withi Tomcat. The ServletRedirector was deployed with the HelloWorldServlet ad will take care of ruig the server-side compoet of the test. ServletRedirector reistatiated HelloWorldServletTest o the server side withi Tomcat ad called testdoget(), which created a istace of the HelloWorldServlet. Because HelloWorldServletTest was ruig withi the servlet egie, it safely created HelloWorldServlet ad was able to call ay ad all methods available i the HelloWorldServlet API. Whe testdoget() completed, ServletRedirector retured to the cliet side, which promptly called eddoget(). The eddoget() method received the WebRespose object, which cotaied the text output by HelloWorldServlet. All this is idepedet of Eclipse. The most iterestig thig about the Cactus test is that you are able to ru the server side ad cliet side withi oe eviromet. So what did it really take to complete these steps? You copied a umber of JAR files ito WEB- INF/lib so that the server-side code would work. You also updated the web.xml file to support the Cactus ServletRedirector, ad you put a umber of JAR files i the project s classpath so the cliet-side compoet would work. You wrote a test that exteded a Cactus base class, you deployed the code to Tomcat, ad the you ra your test code as a JUit test. This example may have seemed like it eeded a lot of setup. I the ormal course of your day-to-day developmet, you will probably use a more comprehesive plug-i to make the developmet of your J2EE applicatio simpler. Plug-is such as Lomboz ad MyEclipse ot oly cotrol the cofiguratio, startig, ad stoppig of applicatio servers, but they also create support files like web.xml. Perhaps by the time this book comes out the Cactus Eclipse plug-i will be released agai, ad the precedig steps will be reduced a bit. Go to itegratio/eclipse/idex.html to check o the plug-i s progress. Better yet, joi i ad help to get it ready.