Getting Started with Java Development and Testing: Netbeans IDE, Ant & JUnit

Transcription

1 Getting Started with Java Development and Testing: Netbeans IDE, Ant & JUnit 1. Introduction These tools are all available free over the internet as is Java itself. A brief description of each follows. They are demonstrated in this example. Java Netbeans latest version of Java. Online documentation and tutorials are also available an integrated development environment. Includes Ant. Ant JUnit tool/classes for automated building and other tasks of software development. tool/classes for unit testing and reporting of code during development To illustrate the usage of these tools as we might want to use them in Extreme Programming (tests are written first) we will introduce a simple example application. 2. Example Application The application supports the following stories. a. There shall be 4 states. Start, Finish and 2 intermediate states. b. The user may navigate between states by using 2 buttons, Next and Back. c. The interface will visually provide feedback about the current system state. A sketch of what the application s Graphical User Interface (GUI) might look like follows: Figure 1: Sketch of application s proposed user interface (GUI). > Start State 1 State 2 Finish Back Next Tools H.O. CS435, M. Wainer page 1

2 Notice that the stories are small and lack many details. The idea is that a customer is readily available for the development team to meet with to work out the details. In this example we will assume all the stories should be implemented for this iteration. The first code that should be written (aside from a spike if necessary) are the tests which help to define what your objects should do. 3. Readying the basic classes - focus on the Model Sometimes it is hard to think about the basic objects when all you can imagine is the sketch of the GUI. However, it is commonly recognized, that the GUI and the underlying functionality are most often better implemented as separate but cooperating objects. The underlying functionality (often referred to as the model) is independent of the particular GUI used to represent and manipulate it. This follows the Model-View-Controller paradigm (see Figure 2). We can develop the model separate from the interface. This better allows porting to different window systems, development of GUI s by trained GUI designers, better use of specialized hardware, etc. There are 2 immediate advantages for us: 1. Development can proceed without needing to know GUI programming; 2. Unit tests are much more easily automated if you don t need to worry about the GUI. Thus we focus first on the model component. This object should be able to represent the states required. It should have methods that allow the view and controller to communicate user manipulation requests and to respond to state queries. The model class for our example is StateModel. Model Underlying, application object, business logic, data, etc. Q. What state are you in? A. Model is in state X User wants to move to next state. GUI View Presents the model to the user. Controller Allows user to manipulate/query the model attributes methods StateModel curstate: keeps current state getstate(): returns current state nextstate(): go to next state backstate(): go back one state Figure 2: The MVC separates the model from the way it is presented and manipulated by the user. Left, the class which represents the model for the example application. Now we can begin to write tests which confirm the behavior of the model. The tests are to be written in Java using JUnit. In effect, the tests will stand in for the View and Controller objects.writing the tests within the Netbeans environment will allow Ant to automatically, compile, execute and generate reports about the tests. Later the Ant script can be modified to switch out the model tests and add in the view and controller code and even deployment tasks. Tools H.O. CS435, M. Wainer page 2

3 4. Using Netbeans for Testing, Implementation, Etc. To get things started faster and how smooth over the process of assuring files are organized properly, begin by creating a working directory for this lab, say labintro. Copy the start.jar and build.xml files to the new directory. Bring up Netbeans and start a new project.(if this is the first time that you are using Netbeans you may also be asked to specify a directory to store your settings. On the Windows machines in the lab use H:\NetBInfo. The H drive is networked so you will have access to your settings even when you use a different PC. a. Use the Project menu to bring up the Project Manager. b. Create a New project (the example name used is toolex) c. Under the Netbeans Explorer you will need to mount a file system for your project. Make sure the Netbeans Explorer is in Filesystems mode. To mount your directory, use the File --> Mount Filesystem menu and specify a Filesystem which is a Local Directory. Select your project directory (labintro). Follow the steps in Figure After creating your new project, mount your working directory for this lab (labintro). This is what you should see in the File Explorer. Clicking on the levers shows what is inside. 2. Double-click on the unjarstart target of the build file. your path to labintro 3. The Ant script executes and decompresses the files contained in the jar file start.jar. 4. If you ve opened the build file close it and then reopen it. A new larger build.xml file should have been loaded from the jar file. 5. Also mount the directory labintro/src as a filesystem. This will allow the IDE to find the source files when it scans for parsing errors. your path to labintro Figure 3: Creating the initial files and directory structure in the labintro directory. your path to labintro/src The Ant script which we will use to automate building, testing and other tasks is in the build.xml file. Sample code to copy and paste is contained in the toolshosrc.txt file. Local property values to customize scripts are placed in the local.properties file. The source code is contained in the directory src/cs435ex1. To start with, you have source code files StateModel and StateModelTester representing the model class and a class for testing it. The model class is just stubbed as we will let the test drive the design. The next section gets us started on the testing and coding. 5. Test First Development with JUnit and Ant The purist approach to Test-First software development writes tests which will always fail at first. They fail because the code for the objects being tested hasn t been written yet so the test cannot possibly pass. Our tests will use the JUnit testing framework. Open the StateModelTester source to examine the first test. See Figure 4. Tools H.O. CS435, M. Wainer page 3

4 /* * StateModelTester.java * * Created on August 21, 2003, 4:25 PM */ package cs435ex1; import junit.framework.*; File name also gives class name We use the JUnit framework /** * wainer */ public class StateModelTester extends TestCase { extending the JUnit class TestCase /** Creates a new instance of StateModelTester */ public StateModelTester(String aname) { super(aname); public static Test suite() { return new TestSuite(StateModelTester.class); Using reflection, tests are collected and run Our test methods all begin with test public void testinitialstate() { StateModel model = new StateModel(); assertequals("check initial state", StateModel.START, model.getstate() ); JUnit provides assert methods for testing Figure 4: A start on the StateModelTester class which uses the JUnit framework to test the StateModel class. This file uses the JUnit framework to specify tests by building tests using asserts to compare the expected and actual results. To compile and run successfully, we must specify where the JUnit framework is. This will likely be different on different machines and that is why the location is specified in the local.properties file. Use the File Explorer to Edit your local.properties file to specify the directory that junit.jar is contained in. After saving you should be able to execute the compile target (in the build file) and eliminate the problems about finding JUnit. The editor will still mark JUnit methods etc. with an X, see the Common Problems section at the end of this handout to fix this. Of course, this test will still fail to compile since the method getstate() and the constant START are not even defined. A purist approach to Test-Driven-Development is to try the test and let the compiler tell you what you need to fix. The advantage of this method is that you won t be implementing things unless you absolutely need them. We will go ahead and add some code to the StateModel class so at least things will compile. Our bare-bones implementation follows. Executing the compile target should now proceed without error. Tools H.O. CS435, M. Wainer page 4

5 Figure 5: Adding just enough code to StateModel so that the first test can compile. /* * StateModel.java * * Created on August 21, 2003, 4:43 PM */ package cs435ex1; /** * wainer */ public class StateModel { static final int START = 1; added to allow compilation /** Creates a new instance of StateModel */ public StateModel() { public int getstate() { return 0; To run the tests, execute the target utest (for unit tests). A graphics display of the success or failure of your tests should appear. A green bar indicates 100% success, a red bar indicates at least one problem. (Figure 6). The compiled byte codes are written to a new directory build Figure 6: The Unit test should compile and run but as expected will fail during execution. 6. Coding to Pass the Test Production coding (and testing) with Extreme Programming is to be done with Pair Programming. That aside, the tests should drive the code. We have a test that failed so we must code what is needed to pass it. In this case, we need to maintain the state with a variable and set it properly Tools H.O. CS435, M. Wainer page 5

6 when initialized. The state also needs to be accurately retrieved. See the modifications in Figure 7 below. Running the utest target should now result in the test passing. package cs435ex1; // make sure to include the package statement public class StateModel { static final int START = 1; private int curstate; /** Creates a new instance of StateModel */ public StateModel() { curstate = START; public int getstate() { return curstate; Figure 7: Adding code to so that the StateModel passes the test. Just enough code was added to pass the test. 7. Repeating the Cycle: Test Coding, Testing, Code Corrections to Pass Tests Obviously we aren t finished yet. Many cycles of writing tests, running tests and coding are needed. A cycle takes on the order of just a few minutes. Figure 8 shows tests for the back and next navigation methods. Run these tests first to assure they fail then use Figure 9 to modify State- Model so that it passes the tests.failing and then passing is more informative than always passing. public void testbasicnavigation() { StateModel model = new StateModel(); model.nextstate(); assertequals("next to State1", StateModel.STATE1, model.getstate() ); model.nextstate(); assertequals("next to State2", StateModel.STATE2, model.getstate() ); model.backstate(); assertequals("back to State1", StateModel.STATE1, model.getstate() ); model.nextstate(); // move to state2 model.nextstate(); // move to finish assertequals("next to Finish", StateModel.FINISH, model.getstate() ); model.backstate(); assertequals("back to State2", StateModel.STATE2, model.getstate() ); Figure 8: Tests for typical navigation behavior using backstate and nextstate methods. We should make sure to test problematic areas. For example, what should happen if we try to move back from the start state or go next from the finish state? The customer should determine what sort of behavior makes sense. Part of the customer responsibility is to write tests for the stories. In this case, our rules will be that a back move from state start does nothing and a next Tools H.O. CS435, M. Wainer page 6

7 move from state finish does nothing. Figure 10 shows the test code for these exception cases. Your test cases should make sure to cover boundary conditions and other unusual cases which may be encountered. Running the Unit tests now will show the red bar as the new boundary tests fail while the earlier tests continue to pass.. public class StateModel { static final int START = 1; static final int STATE1 = 2; static final int STATE2 = 3; static final int FINISH = 4; private int curstate; /** Creates a new instance of StateModel */ public StateModel() { curstate = START; public int getstate() { return curstate; Figure 9: Code to support typical navigation behavior using backstate and nextstate methods and a current state variable. public void nextstate() { curstate++; public void backstate() { curstate--; public void testbndrynavigation() { StateModel model = new StateModel(); model.backstate(); assertequals("back from Start", StateModel.START, model.getstate() ); model.nextstate(); model.backstate(); model.backstate(); model.backstate(); assertequals("back again from Start", StateModel.START, model.getstate() ); // move from start to S1, S2, Finish model.nextstate(); model.nextstate(); model.nextstate(); assertequals("next to Finish", StateModel.FINISH, model.getstate() ); model.nextstate(); model.nextstate(); model.nextstate(); // and try to move further assertequals("nexts at Finish", StateModel.FINISH, model.getstate() ); Figure 10: Tests for navigation behavior at boundary conditions. Tools H.O. CS435, M. Wainer page 7

8 .To pass the new boundary navigation test, modify the code as shown in Figure 11. Figure 11: Revising the nextstate and backstate methods as shown can fix the problem. All tests now pass. Extreme Programming promotes the idea of keeping things simple because You Ain t Gonna Need It (YAGNI). Meaning that we shouldn t be spending a lot of effort designing for all future possibilities since many future plans are frequently changed or cancelled. We used that principle here to design a very simple mechanism for supporting state change. We expect that change will happen so when our current solution is no longer sufficient we will refactor and evolve the design. 8. Creating and Compiling the Application and Interface public void nextstate() { if (curstate < FINISH) curstate++; public void backstate() { if (curstate > START) curstate--; So far we have created the underlying object model and tests for that object. We need to create the actual user application which calls upon the model and supports interaction with the user. While progress is being made in automatic testing tools for GUI code, we will not consider that here. We construct a simple Swing interface for our example Java application; a screen shot is shown in Figure 12. In Xp you might use a spike to quickly test out ideas such as what is required for an interface. Any code developed as part of a spike does not meet the standard of production code (It wasn t developed test-first with pair programming). Figure 12: A java application which uses Swing to provide a GUI for the statemodel. As yet it is not hooked up to the StateModel code. It also fails to provide the user with sufficient feedback since the current state is not indicated. /* * StateApp.java * */ package cs435ex1; import javax.swing.*; import java.awt.*; import java.awt.event.*; /** * wainer */ public class StateApp { Figure 13: StateApp.java, source code to create the application and interface shown in Figure 12. JLabel startlabel; JLabel state1label; JLabel state2label; JLabel finishlabel; JButton nextbut; JButton backbut; public StateApp() { Tools H.O. CS435, M. Wainer page 8

9 Figure 13 continued. public static void main(string[] args) { JFrame frame = new JFrame("Example State Application GUI"); StateApp app = new StateApp(); // Create Buttons app.nextbut = new JButton("Next"); app.nextbut.addactionlistener(new ActionListener() { public void actionperformed(actionevent e) { // make the button click do something ); app.backbut = new JButton("Back"); app.backbut.addactionlistener(new ActionListener() { public void actionperformed(actionevent e) { // make the button click do something ); // group the buttons in a JPanel JPanel buttonpane = new JPanel(); // uses default flow layout buttonpane.add(app.nextbut); buttonpane.add(app.backbut); // Create the labels and have them align at their horizontal centers app.startlabel = new JLabel("Start"); app.startlabel.sethorizontalalignment(jlabel.center); app.state1label= new JLabel("State 1"); app.state1label.sethorizontalalignment(jlabel.center); app.state2label= new JLabel("State 2"); app.state2label.sethorizontalalignment(jlabel.center); app.finishlabel= new JLabel("Finish"); app.finishlabel.sethorizontalalignment(jlabel.center); JPanel labelpane = new JPanel(); // group the labels in a JPanel // Use a GridLayout to align the labels in a single column labelpane.setlayout(new GridLayout(4,1)); labelpane.add(app.startlabel); labelpane.add(app.state1label); labelpane.add(app.state2label); labelpane.add(app.finishlabel); // Place the buttons and labels into the frame frame.getcontentpane().add(buttonpane,borderlayout.south); frame.getcontentpane().add(labelpane,borderlayout.center); frame.addwindowlistener(new WindowAdapter() { // so app exits upon window closing public void windowclosing(windowevent e) { System.exit(0); ); //Finish setting up the frame, and show it. frame.pack(); frame.setsize(340,300); frame.setvisible(true); Tools H.O. CS435, M. Wainer page 9

10 The source code for StateApp.java must be added to the project directory. First you will need to create a new Java class file. It should be stored in a place consistent with its package name. Select the cs435ex1 folder which is mounted as a file system. Hold down the right button to get a popup. You will have a New option and a chance to select Java Class. Do this and name the file StateApp. Its package should be cs435ex1. After you hit finish the file should be created for you in the same place as the other source files. You can copy/paste the code from the toolshosrc.txt file. To run the application (instead of the test code), the build file needs another target. Open the build.xml file for editing. Insert the following to create a run target within your build.xml file. Once you have added the new target, it should appear in the Explorer within the build file. Selecting and executing the run target will run the StateApp class and the GUI will be displayed <target name="run" depends="compile" description="run the Application" > <java classname="cs435ex1.stateapp" failonerror="true" fork="true"> <classpath> <pathelement location="${build.dir/classes"/> </classpath> </java> </target> Figure 14: Ant target to compile and run the application. 9. Connecting the Application to the Model public void updatelabels(statemodel m) { // set all to unselected - black startlabel.setforeground(color.black); state1label.setforeground(color.black); state2label.setforeground(color.black); finishlabel.setforeground(color.black); // query the model to find and show the current state int thestate = m.getstate(); switch (thestate) { case StateModel.START: startlabel.setforeground(color.red); break; case StateModel.STATE1: state1label.setforeground(color.red); break; case StateModel.STATE2: state2label.setforeground(color.red); break; case StateModel.FINISH: finishlabel.setforeground(color.red); break; model.backstate(); // for back button only model.nextstate(); // for next button only app.updatelabels(model); //Make sure the true initial state is shown app.updatelabels(model); Define another method for StateApp. updatelabels is responsible for making sure that the interface reflects the state of the model. Red letters indicate the current state. Put final in front of the declaration for app and add a line to declare a model object. (in main) final StateModel model = new StateModel(); The button handlers act on the model and then query the model s state. (add to both button s actionperformed methods) To make sure the initial state is visualized correctly, query the model s state. (add before frame.pack() ) Figure 15: Code to add to StateApp.java to create the application and interface which utilizes the model. Tools H.O. CS435, M. Wainer page 10

11 Assuming that you have everything working so far, you have a GUI application which runs but is not connected to the model. Our strategy is to make the application act as a wrapper around the functionality of the model. The application is acting as the view and controller components; it needs to instantiate a model object. It will query the object and visualize the object s state in its interface. User interaction (control inputs) are be passed from the application to the model by calling the model object s methods. In a more sophisticated application we would probably use a full implementation of Model-View-Controller. Following the YAGNI idea we just keep it simple here. The code fragments in Figure 15 can be added to the StateApp source to produce the connected working application 10. What Next? If automatic tests aren t used to check the application/interface, manual tests are used. (Passing tests is how we know when we re done.) These tests may be associated with the stories and are provided by the customer (or by closely working with the customer to establish the tests). Developers should also get frequent feedback from the customer about the interface design and appearance. At some point, suggestions must be expressed as new stories and the customer must make the business decisions about which stories have higher priorities. Fixing bugs and glitches are necessarily compared with the value of adding new features. Requests for documentation and enhancements to the user interface can also be treated as stories. 11. Refactoring After a while, changes in code build up and you often realize that things are more complicated than they should be. The code is said to start to smell and it starts to become more error prone and difficult to maintain. Refactoring is the process of reorganizing the code. One way to tell if refactoring is appropriate is to notice if you have nearly identical code which repeats itself several times. In our example, creating JLabels uses several calls which are nearly identical for each label. A refactoring might create a new method which consolidates those calls. Figure 16 shows such a method and how it might be used. // add this method in StateApp public JLabel initlabel(string text) { JLabel lab = new JLabel(text); lab.sethorizontalalignment(jlabel.center); return lab; Figure 16: An example of refactoring that applies to StateApp. The code which creates new JLabels has been simplified by introducing a new method. // Creating Labels is now much simpler labelpane.add(app.startlabel = app.initlabel("start")); labelpane.add(app.state1label = app.initlabel("state 1")); labelpane.add(app.state2label = app.initlabel("state 2")); labelpane.add(app.finishlabel = app.initlabel("finish")); Replace the label creation code in main with the simpler refactored version. Tools H.O. CS435, M. Wainer page 11

12 12. Distribution Since it is important for your customer to obtain and run your application, you must consider how they will be able to do this with a minimum amount of fuss. Projects often consist of many class and other support files. These file are often bundled together to make distribution simpler. Java uses jar files as a standard way to do this. Figure 17 shows another target that can be added to your build file to generate a jar file for distribution. The manifest tells java which class contains main. Jar files can also be tested. One way is to run from the jar file (see figure 17). Another test would be to confirm that it actually contains the files that it should. Windows XP should recognize a jar file with a manifest indicating the main class as a double-clickable executable jar file. <target name="archive" depends="compile" description="creates a distribution jar file" > <jar casesensitive="false" destfile="${dist.dir/stateex.jar"> <fileset dir="${build.dir/classes"> <include name="**/*.class"/> <exclude name="**/*tester.class"/> </fileset> <manifest> <attribute name="main-class" value="cs435ex1.stateapp"/> </manifest> </jar> </target> <target name="runjar" depends="archive" description="run the jarred Application" > <java failonerror="true" fork="true" jar="dist/stateex.jar"/> </target> Figure 17: Ant targets to create a jar file for distribution and to test run it. 13. Final Directory Structures your path to labintro build/classes directory - compiled code is placed here. Directory is created by Ant. src directory - Our source files are placed here in subdirectories corresponding to package names. The same directory is mounted again. We mount this directory separately to enable the IDE to parse the files for errors. your path to labintro/src byte codes the compiled byte codes belonging to the cs435ex1 package dist directory - files ready for distribution placed here. Directory is created by Ant. Ant files - build.xml and local.properties. Ant runs targets in the build file. toolshosrc.txt - contains code from the H.O. for you to copy & paste. Tools H.O. CS435, M. Wainer page 12

13 Common Problems Extra subdirectories appear Make sure you have included the package statement in your source files. Check the relative positions of your files (see Figure 3 especially step 5) Can t compile test code Make sure the JUnit files are installed and the path element in your build file is given for its location. Annoying glyphs appear in the source editor The editor is scanning the files and if it can t find a particular package (like JUnit) all the functions from that file will be flagged with a red boxed x. You can tell the editor where the package is located, the scan will succeed and the glyphs will go away. From the main window open the Tools Menu and select Options (see Figure below). You ll want to pick the Editing section, Java Sources subsection and select the Expert tab. Change the Parser Class Path so it gives the location of the package which the IDE can t find. You may have to wait for the IDE to rescan the file before it notices that the statements can be parsed and removes the glyph. Editing Section; Java Sources subsection Update this path Expert tab Tools H.O. CS435, M. Wainer page 13

14 Notes: Tools H.O. CS435, M. Wainer page 14