Core XP Practices with Java and Eclipse: Part 1

Transcription

1 1. Introduction Core XP Practices with Java and Eclipse: Part 1 This tutorial will illustrate some core practices of Extreme Programming(XP) while giving you a chance to get familiar with Java and the Eclipse IDE. The tools we will use are cross-platform and free off the web. Java - Object-oriented language and technology Eclipse - an open extensible IDE Junit - testing framework for Java unit tests Ant - Java-based build tool To illustrate these tools, we start with a simple Tic-Tac-Toe example application. 2. Example Application In XP, requirements are expressed as stories. These are short descriptions of features or qualities of the software that the customer desires. As an example consider a Tic-Tac-Toe game application. Traditionally in XP stories are written on index cards. Here they are listed below. 1. Allow 2 players to play a game of Tic-Tac-Toe on the computer. 2. Allow the players to input their move graphically (click on the board position). 3. The computer should prohibit illegal moves. 4. The computer should ascertain when the game is over and announce the winner. 5. The computer should indicate which markers formed part of a winning sequence. 6. After a game is completed, it should be easy to play another game. In XP, the initial list of stories may change over the life of the project. Some stories may not be implemented at all and new stories may be added. Developers will need further communications with the clients to specify details about stories and to determine if the stories have been implemented correctly. 3. Getting Started XP uses minimal up front planning. Even so, before diving into the code there is group discussion about what is to be accomplished. To get everyone on the same page, a metaphor is often used. Here we might say that this Tic-Tac-Toe game application should be a very straight-forward adaptation of the paper version. Early discussions most often involve the user and might use techniques such as paper prototyping to make more clear what the customer envisions. Software developers may even make some informal sketches of class diagrams and other forms of UML diagrams. The customer decides which stories are most important. Developers give feedback about the estimated effort required to implement each story. O X X O A sketch showing the major interface component. A board which allows the user to enter moves by clicking on a position. Our brainstorming might also surmise that we need to keep track of whose turn it is and what markers are placed on the board. Perhaps we could use an array to store the board. Figure 1: Early brainstorming and sketch of application s proposed user interface (GUI). javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

2 4. 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 store and represent the required state information. For instance, whose turn is it?, what is already on the board?. The model hides its internal data structures but should have methods that allow the view and the controller to communicate user manipulation requests and to respond to queries. The model class for our example is TTTGame. GUI Q. What is on the board so far? View attributes methods Model Underlying, application object, business logic, data, etc. TTTGame playertomove: keeps track of which player s turn it is... getwhoseturn(): returns the player whose turn it is.... 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 Eclipse environment will demonstrate some of the features of that environment. We use Ant to help automate and manage development tasks. As our projects get larger automation becomes more important; getting these scripts to work properly might be an element of risk so we try to tackle it early. 5. Setting up a new Java project in Eclipse A. board positions with markers User wants to place another marker on board. Presents the model to the user. Controller Processes user requests to manipulate/query the model. Supplies view(s) with information from the model. Figure 2: The MVC separates the model from the way it is presented and manipulated by the user. Left, representative methods from the class which represents the model for the example TTTGame application. 1. Decide where you want to place your Java projects. Eclipse uses the idea of a workspace directory to store projects in. You can make Eclipse start up using your preferred workspace. If you are working in the lab and make use of a networked drive your work will be available to you no matter what machine you are on. 2. Create a new Java project (File --> New --> Project --> Java Project). Let Eclipse make a project directory for you in your workspace (See Figure 3). Pick a name that will be easy for you to recognize (tttproj). javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

3 Don t worry about the other options in this dialog since we will be using an Ant build script to control the compile and run procedures. Figure 3: Eclipse 3.0, New Java Project dialog. Define project name and hit Finish. Within your project directory it is good practice to group different types of files into different directories. In particular it is generally a good idea to keep your source code separate from the compiled code. Java also uses a close correspondence between java packages and directories. It makes life much easier to set up these directories carefully early on so they work well with the build script. Add a new source folder to your project called src (for source code files). Add a package (tttex) to the src folder. See Figure 4. Figure 4: Highlighting the src directory and popping up the right menu is an easy way to create a New Package within the src directory. javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

4 3. Since we are getting used to Xp practices, we will start with Test First Development (TFD) How do we express a test for code that doesn t exist? Think about how we would want to use the system if it did exist and how could we tell if it was working correctly. Start simply. For instance, when the application starts, the model should be initialized to some well defined start state. The view will need to query the model for its state information so it can be visually represented accurately on the display. An easy place to start might be that the model should be initialized so it is player X s turn. Rather than coding the model first, we code a test assuming the model does what we want. These tests can be placed into a separate class. They use assert calls so that they can automatically verify correctness. Such a test might look like what is shown in Figure 5. The JUnit framework provides various assert methods to compare results to what is expected. The framework automatically calls methods which start with the word test. package tttex; import junit.framework.testcase; public class TTTGameTester extends TestCase { public void testfirstturn() { int whoseturn; TTTGame game = new TTTGame(); whoseturn = game.getwhoseturn(); assertequals("initial player turn", TTTGame.PLAYER_X, whoseturn); Figure 5: A test to see if the game correctly starts with the turn belonging to player X Position the cursor over the lightbulb to see possible solutions Figure 6: Eclipse feedback to show error lines and possible solutions. Create a new java class named TTTGameTester in the tttex package (select the package and use the right button pop-up menu: New --> Class). Replace the contents of the file by Copy/Pasting from Figure 5. Eclipse will scan the code and indicate lines which may contain errors (red x boxes). Lightbulbs show that Eclipse has some possible suggestions for fixes. See Figure 6. If you hold the cursor down over the top lightbulb (a suggestion fo r the problem with the import statement) suggestions will pop-up. Select the one which adds the JUnit library to this project (the last choice). The package view on the right will show another library (junit.jar) added to your project and the source code will have only 2 problem lines left. These problems are because the class TTTGame does not exist. javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

5 4. To get the test to compile, let s create the TTTGame class. The goal is to keep it simple and to get it compile with a minimal amount of work. Create the TTTGame class shown in Figure 7. package tttex; public class TTTGame { public static final int PLAYER_X = 2; public int getwhoseturn() { return 0; Figure 7: A simple TTTGame class so that we can compile the test code. 5. To actually compile and run the test, we need to add in our build file for Ant. A generic starting file for this purpose is given in Figure 8 This is not Java it is an XML build file for Ant. Store it at the top level of your project directory and name it build.xml.(new --> File, create as a simple file) <?xml version="1.0" encoding="utf-8"?> <!-- build.xml, for Ant to manage Java projects, cs435, Wainer --> <project basedir="." default="compile"> <property file="local.properties"/> <property name="build.dir" value="build"/> <property name="src.dir" value="src"/> <property name="dist.dir" value="dist"/> <target name="init" description="creates temporary directories" > <mkdir dir="${build.dir/classes"/> <mkdir dir="${dist.dir"/> <target name="clean" depends="init" description="removes temporary directories" > <delete dir="${build.dir"/> <delete dir="${dist.dir" failonerror="false"/> <delete file="start.jar"/> <target name="compile" depends="init" > <javac debug="true" deprecation="true" destdir="${build.dir/classes" srcdir="${src.dir" verbose="true"> <classpath> <!-- gives location of junit framework objects to java compiler --> <pathelement location="${junit_home/junit.jar"/> </classpath> </javac> Figure 8: A generic starting file for Ant. Save as build.xml. (listing continues) javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

6 <target name="testmodel" depends="compile" description="execute Unit Tests" > <java classname="junit.swingui.testrunner" failonerror="true" fork="true"> <arg value="pack.modeltester"/> <classpath> <pathelement location="${junit_home/junit.jar"/> <pathelement location="${build.dir/classes"/> </classpath> </java> <target name="run" depends="compile" description="run the Application" > <java classname="pack.someapp" failonerror="true" fork="true"> <classpath> <pathelement location="${build.dir/classes"/> <pathelement location="${build.dir/.."/> </classpath> </java> <target name="archive" depends="compile" description="creates a distribution jar file" > <jar casesensitive="false" destfile="${dist.dir/some.jar"> <fileset dir="${build.dir/classes"> <include name="**/*.class"/> <exclude name="**/*tester.class"/> </fileset> <fileset dir="."> <include name="images/*"/> <include name="sounds/*"/> </fileset> <manifest> <attribute name="main-class" value="pack.someapp"/> </manifest> </jar> <target name="runjar" depends="archive" description="run the jarred Application" > <java failonerror="true" fork="true" jar="dist/some.jar"/> </project> Figure 8(continued): A generic starting file for Ant. See text for instructions. After the file has been saved you should see it (with an ant icon ) in the package editor. Right menu it and open it with the Ant editor. If the code pasted over a little ugly, you might want to move the cursor to the editor, get the pop-up menu and select the format option to clean things up. The file given in Figure 8 still needs to be customized for your project. Using the editor menu s Find/Replace options (use the javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

7 case sensitive option), change PACK to tttex, and SOME and MODEL to TTTGame. Save your file. Note the outline view at the right shows the various Ant targets in your file (init, clean, testmodel...). 6. Run the test by selecting the testmodel task in the Ant Outline view and getting the right button menu. Select Run --> Ant Build (the first option without the...). If you haven t saved source files you ll be given a chance to do so. The instructions in the build file will be executed by Ant. The build file contains dependency information so it knows, for instance, that before running the test, the code should be compiled. As the script is executed, information is sent to the Eclipse console. In this case, you will see that the compile could not succeed because of 3 errors. These errors are due to the compiler not being able to find the JUnit framework. The build script is giving specifics about how to compile your code: where the source and libraries are, where to store the byte code etc. Since you (or possibly your team-mates) may be running this code on different machines, some things such as library locations may change. To allow for easy customization, a file called local properties should be created within your project directory. It defines a script variable, junit_home, which gives the location of the JUnit directory on your machine. No matter what platform you are using, subdirectories along this path should be separated by forward slashes. You can find this information very easily by clicking on the JUNIT_HOME icon for your project shown in the Package window. An example is given in Figure 9. (Note, all slashes are forward slashes even on Windows). #define junit_home as the directory where junit is on your system junit_home=d:/eclipse/plugins/org.junit_3.8.1 Figure 9: An example of a local.properties file. It defines the directory holding the JUnit jar. After you have created and saved your local.properties file, try running the testmodel task again. It should run (it might take a while to start up) and display graphical feedback for your JUnit test. The red bar indicates at least one test did not pass. Figure 10: Red bar feedback from JUnit tests shows at least one test failed to pass. javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

8 7. It is good practice to have the test fail initially. Fixing it then gives a greater confidence not only in the feature itself but also in the test. Here the test failed because the method getwhoseturn() returns the number 0 instead of the value for PLAYER_X. A simple correction should fix the problem. Make it return PLAYER_X. Later we know this will have to be more complex (it won t always be player X s turn) but for now this is the simplest thing that will work. Make the change and run the test again. You should get the green bar feedback indicating that all your tests have passed. 6. Building up your code incrementally using TFD At this point you have a start. What should the next mini-goal be? How about making sure that the board itself is initialized properly. Here you might do some brainstorming about what sort of information the board might contain and what sort of interface you will provide to access it. One choice might be to represent what is on the board with integer constants and to represent the board with an integer array. We can make a call to the model and it can pass back a copy of the integer array representing the current contents of the board. The first thing to code is another test. Add the following new method to the TTTGameTester class. (Figure 11) public void testinitboard() { int[] theboard; TTTGame game = new TTTGame(); theboard = game.getboard(); boolean allclear = true; for (int i =0; i<9; i++) { if (theboard[i]!= TTTGame.EMPTY) { allclear = false; break; asserttrue("board should be empty",allclear); Figure 11: A new test to confirm the board is initialized correctly. The IDE (or the compiler if you try it) flag errors because getboard() and TTTGame.EMPTY are not defined. That tells us what we need to work on in the TTTGame class. See the code in Figure 12. package tttex; public class TTTGame { public static final int PLAYER_X = 2; public static final int EMPTY = 0; public int getwhoseturn() { return PLAYER_X; public int[] getboard() { return new int[9]; Figure 12: TTTGame class is updated to include EMPTY and getboard(). javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

9 Update the TTTGame class and try to run the tests. You might be surprised to see that the tests actually pass. Obviously these functions are still too simple right? If they need to be more complicated then write a test that fails with the software s current version. Add just enough complexity to make the tests pass. Exercises: a. Write a test to see if a marker can be placed on the board at a desired location. (What design issues come up? Should you be able to place a marker anywhere?) b. Write a test to see if the player s turn is updated once a move is made. Your tests should be clearly named and developed one at a time. Running the tests should give the green bar show of success. The TTTGame class should only be made as complicated as needed to pass the tests. As you continue working, you should fix any previous tests that break. If older tests no longer make sense or need to be modified, then change them. Use descriptive test names and meaningful assert comment strings. Think ahead to how the GUI (view/controller) will interact with the model. The view will have to ask the model everything necessary to be able to visualize it. The controller will have to be able to forward user requests to the model. The JUnit tests should call the same model methods that the GUI will need to call. c. Suggest 2 more tests that are needed to develop/test the logic of the model. If you can t think of anymore for the first 3 stories, also consider the 4th story. PROBLEMS/NOTES: Ant Build can t find compiler (javac) - an error experienced when trying to compile code using an Ant script from within Eclipse sometimes occurs on Windows XP. Ant cannot find where the compiler is. A solution is to go to Eclipse s Window Menu. Select Preferences -> Ant -> Runtime. Pick the Classpath tab and access the Global properties. From here, Add External Jars. You ll want to find and select the tool.jar underneath the Java jdk lib directory. That should solve the problem. (In the 2102 lab check under D:\Program Files\Java\jdk1.5.0\lib) An error (Virtual Machine not found) may occur when trying to run Ant scripts. Go to the Run Menu, select External Tools and then the External Tools... option. Highlight the build.xml file. Select the JRE tab. Make the JRE separate and select an installed jdk. Next Topic: Visualizing the Game - Starting on the Graphical User Interface Considering the time available and the customer s priorities, our first iteration will only focus on stories 1 through 3. While the game logic should remain in the TTTGame class, we ll also need to get development going for the interface. Some of this development would naturally proceed in parallel in a larger group. javaxpgetstarted1.s05, prepared by Michael Wainer, Spring

10 Eclipse 3.0 IDE showing Java perspective and JUnit GUI test runner in foreground. javaxpgetstarted1.s05, prepared by Michael Wainer, Spring