From 56wiki

CS56—Advanced Applications Programming—W12

= Wiki Edits for Choice Points =
* Typo report for [[W12:Labs:lab01]]

lab01: Using Ant to manage our builds, and JUnit for Test-Driven Development

Overview

This lab will introduce you to the idea of using Ant to manage your build process (i.e. compiling and running) and using Ant with JUnit to write unit tests.

Ant is similar in purpose to the "make" utility that may be familiar to you from C/C++ programming on Unix systems. Ant is designed with Java in mind, and uses a standard XML-based syntax—similar to the syntax of the HTML code used to make web pages—other than the idiosyncratic syntax used for writing Makefiles.

JUnit is one of the most popular tools for supporting test-driven development. It has influenced the test-driven development tools for many other languages (CxxUnit, PHPUnit, etc.)

Familiarity with Ant and JUnit are essential real-world skills that you need in your toolbox before you can be considered an expert level professional Java developer—and even if you never encounter Java again after this course, you are likely to encounter similar tools in other programming environments.

Step-by-Step Instructions

Step 1: Preparing directories and files

Start by creating a directory ~/cs56/lab01.

Then copy the UCSBCourse.java and UCSBCourseTester.java files that you made in lab00 into your ~/cs56/lab01 directory---we are going to continue with the same file from last week.

• We can hope that by now your Unix skills are solid enough that you know how to do that, but if not, it is ok to ask a classmate for help. Try that before asking the TA—and try to make a note of how to do it for next time.

Next, we are going to compile these programs just as you did in lab00, to:

• make sure they still compile, and
• remind you how do do that.

The easiest way to compile is with the command:

javac *.java

And the way to run the main from UCSBCourseTester is with:

java UCSBCourseTester

However, we'll seldom use those commands directly again, because from here on out, we are switching to using Ant, a Java-based tool similar in purpose to the make utility often used with C/C++ programming.

To use Ant, our first step is to create a build.xml file so that we can automate this process using Ant. That's probably overkill for a simple project such as this one, but we are going to progress to much more complicated code quickly, and it will be nice to have a tool like Ant to help us.

Step 2: Creating a simple build.xml file

Here's a minimal build.xml file with just two targets: compile and run:

<project default="compile">

  <!-- build.xml for lab01, W12, CS56
       name: @@@ INSERT YOUR NAME HERE BEFORE SUBMITTING @@@ -->

  <target name="compile" description="compile my code">
    <javac srcdir="." destdir="." includeantruntime="false" />
  </target>

  <target name="run" description="run the UCSBCourseTester program">
    <java classname="UCSBCourseTester" classpath="." />
  </target>

</project>

Copy this code into a file called build.xml in the current directory.

Step 3: Working with the build.xml file

First, try this command: ant -p

The ant -p command gives you a list of the "targets" in the file—i.e. the things you can do with the file. Each target has a name and a description, and those are listed by the ant -p command, as this example output shows:

-bash-4.1$ ant -p
Buildfile: build.xml

Main targets:

 compile  compile my code
 run      run the UCSBCourseTester program
Default target: compile
-bash-4.1$ 

Next, try this command:

ant compile

You should get output like this:

-bash-4.1$ ant compile
Buildfile: build.xml

compile:
    [javac] Compiling 2 source files to /cs/faculty/pconrad/cs56/lab01

BUILD SUCCESSFUL
Total time: 1 second
-bash-4.1$ 

If you repeat the command, you'll get output like this:

-bash-4.1$ ant compile
Buildfile: build.xml

compile:

BUILD SUCCESSFUL
Total time: 0 seconds
-bash-4.1$ 

Just like with the make utility commonly used in CS16/CS24/CS32 for C/C++ code, the Ant utility can tell when the files don't need to be compiled again--i.e. when the .class files are already newer than the .java files. However, if you make a change to either of the .java files (try it!) or you delete the .class files and try the command again, the compile will happen again.

Try this to convince yourself that this is true.

Step 4: More exploration with Ant

Try these things:

(1) Try just typing ant instead of ant compile. Note that it does the same thing. Look at the build.xml source code and see if you can figure out why.

(2) Then, try typing ant run and see what happens.

(3) Next, try deleting the .class files (remember the rm command) and try doing ant run without first doing ant compile. See what happens.

When you've done those things, go on to step 5

Step 5: Explanation of the build.xml file

Here's some additional explanation:

The first line:<project default="compile"> says that

• this XML file contains a project
• the default for this project is to do the target called "compile"
• the default is "what will happen" if you just type ant at the command line—it's the same as if you had typed ant compile

The next part is a comment:

Anything inside <!-- and --> is a comment in XML, and therefore also inside a build.xml file. (HTML uses the same comment syntax.)

Then, we have two targets. The first one is for compiling:

 <target name="compile" description="compile my code">
    <javac srcdir="." destdir="." />
  </target>

This says: compile every .java file from the srcdir, and put the resulting .class files in the destdir. Since both are ., which means current directory, that's exactly what happens.

The next one is for running our code:

   <target name="run" description="run the UCSBCourseTester program">
    <java classname="UCSBCourseTester" classpath="." />
  </target>

This says: run the main() method of the class UCSBCourseTester—and you should find the .class file in the current directory (i.e. classpath=".").

Finally, the last line says that the build.xml is finished:

</project>

Step 6: Some improvements to the build.xml file

We can improve our build.xml file by:

• adding a clean target
• adding a dependency between the run and compile targets.

To add a clean target, add the following block of code right before the </project> close tag. This says that when we type ant clean we want to delete every file in the current directory (dir=".") that ends in .class (includes="*.class"). You can find out what the failonerror="false" verbose="true" parts mean by looking at the documentation for Ant here: http://ant.apache.org

  <target name="clean" description="delete unnecessary files and directories">
    <delete failonerror="false" verbose="true">
      <fileset dir="." includes="*.class" />
    </delete>
  </target>

After you make the change above, make one more change: on the open tag of the run target, change it to this:

 <target name="run" depends="compile" description="run the UCSBCourseTester program"> 

That says that anytime we ask for ant run, automatically invoke ant compile first.

Once you've made those changes, try the commands below in sequence and observe what happens.

Then, try this whole sequence of steps a second time, and try to predict in advance what you will see—that is, each time, can you predict whether anything will actually be compiled, or deleted?

ant clean
ant compile
ant clean
ant run
ant clean
ant compile
ant run
ant clean
ant clean
ant compile
ant compile

At this point, you should have at least an initial idea of how a build.xml works. I'll introduce more features of Ant in future labs—and I'll also invite you to learn some of those on your own by doing your own reading. The wiki page for Ant has lots of suggestions for where to look.

Step 7: Adding properties

Next, we are going to add a few things into our build.xml file to allow us to generate Javadoc.

We are going to want to write our Javadoc into the following web address:

http://www.cs.ucsb.edu/~username/cs56/lab01/javadoc

where, username is replaced by your actual username.

In order to be able to substitute your username in an ant build.xml file, we need to add the following lines of code near the top of our build.xml file. I suggest putting these immediately after the comment block that has your name in it:

   <property environment="env"/> <!-- load the environment variables --> 
   <property name="webRoot" value="${env.HOME}/public_html/cs56" />
   <property name="webBaseURL" value="http://www.cs.ucsb.edu/~${env.USER}/cs56" />

First lets consider what the following line does:

 <property environment="env"/> <!-- load the environment variables --> 

This line line loads up all the environment variables from the shell—all the things that come up when you type env at the shell prompt. Try typing env at the shell, and you should output something like this (I've shortened the output below considerably). You can see that HOME and USER are two of the things that are defined.

-bash-4.1$ env
HOSTNAME=csil.cs.ucsb.edu
TERM=xterm-color
SHELL=/bin/bash
USER=pconrad
PATH=/bin:/usr/lib/qt-3.3/bin:/usr/lib/mpich2/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin
PWD=/cs/faculty/pconrad/public_html/cs56/examples/mvc/areaOfTriangle.02
LANG=en_US.UTF-8
HOME=/cs/faculty/pconrad
-bash-4.1$ 

The next two lines define two properties (these are variables that the build.xml file can use later):

   <property name="webRoot" value="${env.HOME}/public_html/cs56" />
   <property name="webBaseURL" value="http://www.cs.ucsb.edu/~${env.USER}/cs56" />

The syntax ${env.HOME} means to substitute the value of the HOME environment variable (i.e in my case /cs/faculty/pconrad. So the first definition means that anytime later that we write ${webRoot} what will be substituted in place of that is /cs/faculty/pconrad/public_html/cs56. But for you, the ${env.HOME} will result in your home directory.

Similarly, ${env.USER} gets replaced with your username, so for me, when I use this file, and write ${webBaseURL} later in the file, it will be replaced with http://www.cs.ucsb.edu/~pconrad/cs56, but for you it will get replaced with an appropriate URL that contains your username.

Step 8: More properties

Next, add three more lines into the build.xml that define properties. These build on the lines we added in the previous step:

  <property name="projectName" value="lab01" /> 
  <property name="javadocDest" value="${webRoot}/${projectName}/javadoc" /> 
  <property name="javadocURL" value="${webBaseURL}/${projectName}/javadoc" /> 

Now, we have properties that will specify the full directory name and the full URL of where the Javadoc is going to be written.

We are ready to actually add the step that creates the Javadoc.

Step 9: Adding the Javadoc step

Next, add another target into the build.xml file. You can add this one anywhere, as long as it is between two other targets.

I suggest adding it at the end, right before the </project> close tag.

   <target name="javadoc" depends="compile">                                                        
                                                                                                  
   <delete dir="javadoc" quiet="true" />                                                          
   <javadoc  destdir="javadoc" author="true" version="true" use="true" >                          
      <fileset dir="." includes="**/*.java"/>                                                     
      <classpath>                                                                                 
          <pathelement location="/cs/faculty/pconrad/public_html/cs56/lib/junit-4.8.2.jar"/>      
     </classpath>                                                                                 
   </javadoc>                                                                                     
                                                                                                  
   <!-- delete the old javadoc -->                                                                
   <delete quiet="true" dir="${javadocDest}" />                                                   
                                                                                                  
   <!-- copy everything you just made to the javadoc destination, and then make it readable -->   
                                                                                                  
   <copy todir="${javadocDest}" >                                                                 
     <fileset dir="javadoc"/>                                                                     
   </copy>                                                                                        
                                                                                                  
   <!-- Note: this only does the chmod command on the                                             
        javadoc subdirectory and its contents.  You MIGHT have to                                 
        MANUALLY do the chmod on the parent directories.  However,                                
        you should only need to do that once. -->                                                 
                                                                                                  
   <chmod dir="${javadocDest}" perm="755"  type="dir" includes="**" />                            
   <chmod dir="${javadocDest}" perm="755"  type="file" includes="**/*" />                         
   <echo>Javadoc deployed to ${javadocURL}</echo>                                                 
                                                                                                  
 </target>        

 <pathelement location="/cs/faculty/pconrad/public_html/cs56/lib/junit-4.8.2.jar"/>      

The target above is a bit of a long target, and it contains a number of steps. Those individual steps are called Ant tasks—that is, all of the following are Ant tasks:

You may be wondering why we have special XML versions of things that in Makefiles are just done as Unix commands. But that's just it—this is one of the big advantages of Ant over make: since Ant is itself written in Java, it is cross-platform. Makefiles usually contain lots of Unix commands, and are therefore of limited usefulness, on, say, a Windows system (unless you install a lot of third-party software such as Cygwin.) But if you have a JVM, Ant will just work.

And the same version runs on Windows, Mac and Linux—check out the download links at http://apache.ant.org and you won't see separate versions for different platforms.

You can learn more about all the different Ant Tasks by looking at the documentation for Ant at http://apache.ant.org

But enough discussion—let's try it out. If it works, we should be able to type ant javadoc and get a URL that we can put in our browser:

Step 10: Trying out the Javadoc step

Try typing ant javadoc and see what you get. What you hope for is something like this:

-bash-4.2$ ant javadoc
Buildfile: /cs/faculty/pconrad/cs56/lab01/build.xml

compile:
    [javac] Compiling 1 source file to /cs/faculty/pconrad/cs56/lab01

javadoc:
   [delete] Deleting directory /cs/faculty/pconrad/cs56/lab01/javadoc
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Creating destination directory: "/cs/faculty/pconrad/cs56/lab01/javadoc/"
  [javadoc] Loading source file /cs/faculty/pconrad/cs56/lab01/UCSBCourse.java...
  [javadoc] Loading source file /cs/faculty/pconrad/cs56/lab01/UCSBCourseTest.java...
  [javadoc] Loading source file /cs/faculty/pconrad/cs56/lab01/UCSBCourseTester.java...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.6.0_22
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
   [delete] Deleting directory /cs/faculty/pconrad/public_html/cs56/lab01/javadoc
     [copy] Warning: allclasses-frame.html modified in the future.
     [copy] Warning: allclasses-noframe.html modified in the future.
     [copy] Warning: deprecated-list.html modified in the future.
     [copy] Warning: help-doc.html modified in the future.
     [copy] Warning: index-all.html modified in the future.
     [copy] Warning: index.html modified in the future.
     [copy] Warning: overview-tree.html modified in the future.
     [copy] Warning: stylesheet.css modified in the future.
     [copy] Warning:  modified in the future.
     [copy] Copying 21 files to /cs/faculty/pconrad/public_html/cs56/lab01/javadoc
     [echo] Javadoc deployed to http://www.cs.ucsb.edu/~pconrad/cs56/lab01/javadoc

BUILD SUCCESSFUL
Total time: 6 seconds
-bash-4.2$ 

That URL at the bottom, i.e. http://www.cs.ucsb.edu/~pconrad/cs56/lab01/javadoc is one that you should be able to put in your browser, and see lovely Javadoc—looking something like this screen shot:

What if I see the message "Warning: ... modified in the future"

This is usually a message that can be ignored. See: Ant#Modified_in_the_Future for more information.

Step 11: More build.xml adjustments

Step 11a: Adding javadoc into the clean target

Now that we are generating javadoc, we may want to add something into the clean target that clears out the javadoc from our current directory. This will leave the version on the web alone, but it will clear out the javadoc subdirectory of ~/cs56/lab01—this is helpful, because we don't need to include all that javadoc stuff in our turnin command. (The TA will look for it on the web instead.) Clearing it out will save on disk space too.

Previously, our clean target looked like this:

<target name="clean" >
    <delete failonerror="false" verbose="true">
      <fileset dir="." includes="*.class"/>
    </delete>
  </target>

We are going to add just one extra line, like this:

<target name="clean" >
    <delete failonerror="false" verbose="true">
      <fileset dir="." includes="*.class"/>
    </delete>
    <delete dir="javadoc" quiet="true" />
  </target>

Step 11b: Adding debug information

Finally, inside the javac task, add these attributes to the <javac ... > open tag:

debug="true" debuglevel="lines,source"

After you do, the open tag should look like this:

     <javac srcdir="." destdir="." debug="true" debuglevel="lines,source" includeantruntime="false"/>                   

This is similar to adding the -g flag when you compile C/C++ code—it makes sure that when you have error messages, you get a file number and a line number, so you know where to look in your code for the problem. For a more detailed explanation, see:

Ant#I_get_.22.28Unknown_Source.29.22_in_my_stack_traceback_messages

Step 12: Test Driven Development with JUnit

JUnit is a Java package that supports Test-Driven Development. If you aren't familiar with the concept, you may want to read up on the basic ideas of Test-Driven Development at the following link before moving on. (If you had Conrad for CS8 or CS16, though, you've definitely seen this idea before. You still might find the article interesting though.)

• http://en.wikipedia.org/wiki/Test-driven_development

Step 12a: Add a JAR file for JUnit to the Classpath

To use JUnit, we need access to the "JAR" file for JUnit. A JAR file is a "Java Archive"---a collection of .class files that's been essentially "zipped up" (compressed) into a single file.

You can find that JAR file at the following link:

 /cs/faculty/pconrad/public_html/cs56/lib/junit-4.8.2.jar

We are going to specify that location in our build.xml file so that you don't have to copy the .jar file into your current directory (taking up your precious disk quota.)

To do that, we need to change the compile target in our build.xml file as follows. Note that what we've done is to first remove the self-closing tag /> and replace it with a proper close tag </javac>. We've then nested a <classpath> element inside that tells javac where to look for classes as it is compiling.

 <target name="compile" >  
   <javac srcdir="." destdir="." debug="true" debuglevel="lines,source" includeantruntime="false">                                                                                                          
                                                                                                                                              
     <classpath>                                                                                                                              
         <pathelement location="."/>                                                                                                          
         <pathelement location="/cs/faculty/pconrad/public_html/cs56/lib/junit-4.8.2.jar"/>                                                   
     </classpath>                                                                                                                             
    </javac>       
 </target>

Step 12b: Add a target to the build.xml file to run JUnit

Next, we need to add a test target that runs JUnit. Here's the code to copy in, right before the </project> close tag. This one's a little long, and we won't explain all of it right now.

  <target name="test" depends="compile">

    <junit haltonerror="no" haltonfailure="no">
       <classpath>
         <pathelement location="/cs/faculty/pconrad/public_html/cs56/lib/junit-4.8.2.jar"/>
         <pathelement location="."/>
       </classpath>

       <batchtest fork="yes">
          <fileset dir=".">
            <!-- this will pick up every class with a name ending in Test -->
            <include name="*Test.java"/>
          </fileset>
       </batchtest>

        <formatter type="plain" usefile="false" /> 
       
    </junit>
  </target>

Step 12c: Create a JUnit test class

With this in place, we should be able to add a JUnit test class. Here's what will go into UCSBCourseTest.java (note the difference—UCSBCourseTest.java, not UCSBCourseTester.java)

http://www.cs.ucsb.edu/~pconrad/cs56/12W/labs/lab01/code/UCSBCourseTest.java

The two methods in this class, are the JUnit equivalents of what we did in UCSBCourseTester.java (our main program where we tested by just using if/else and System.out.println). The comparison between the actual and expected values, and the printing of "passed" or "failed" is now automated.

Step 12d: Running the test

To run, type ant test and the unix command prompt.

If both of your tests pass, you should see the following output.

-bash-4.2$ ant test
Buildfile: /cs/faculty/pconrad/cs56/W12/lab00/build.xml

compile:
    [javac] Compiling 1 source file to /cs/faculty/pconrad/cs56/W12/lab00

test:
    [junit] Testsuite: UCSBCourseTest
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.027 sec
    [junit] 
    [junit] Testcase: test_getDept took 0.005 sec
    [junit] Testcase: test_getNum took 0 sec

BUILD SUCCESSFUL
Total time: 3 seconds
-bash-4.2$ 

Here's what failing test output looks like:

-bash-4.2$ ant test
Buildfile: /cs/faculty/pconrad/cs56/W12/lab00/build.xml

compile:

test:
    [junit] Testsuite: UCSBCourseTest
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0.034 sec
    [junit] 
    [junit] Testcase: test_getDept took 0.006 sec
    [junit] Testcase: test_getNum took 0.005 sec
    [junit] 	FAILED
    [junit] expected:<[3A]> but was:<[stub]>
    [junit] junit.framework.AssertionFailedError: expected:<[3A]> but was:<[stub]>
    [junit] 	at UCSBCourseTest.test_getNum(Unknown Source)
    [junit] 
    [junit] Test UCSBCourseTest FAILED

BUILD SUCCESSFUL
Total time: 1 second
-bash-4.2$ 

So that you can see failing test output, do this:

• You know that you already have a "good" copy of UCSBCourse.java in the directory ~/cs56/lab00 from last week.
• So, temporarily, copy the "starting point" file with the "stubs" in it over the top of your ~/cs56/lab01/UCSBCourse.java
  • You can find that file at /cs/faculty/pconrad/public_html/cs56/12W/labs/lab00/UCSBCourse.java
  • Or, on the web at http://www.cs.ucsb.edu/~pconrad/cs56/12W/labs/lab00/UCSBCourse.java
• After you see what "failed tests" look like, you can restore your copy from ~/cs56/lab00/UCSBCourse.java

Step 13: Adding new tests (similar to ones from old UCSBCourseTester.java)

Now, compare:

• the code in the UCSBCourseTester.java file, which contains four tests written by hand
• the code in UCSBCourseTest.java, where we have two tests written in the JUnit style that correspond to the first two from UCSBCourseTester.java.

By following the example, create two additional JUnit style tests for the ones that are missing from UCSBCourseTest.java (i.e the third and fourth tests in UCSBCourseTester.java).

Try your code with both the original UCSBCourse.java file (the one from my website with the stubs in it), as well as with your "fixed" code from lab00.

When you have four JUnit-style tests in UCSBCourseTest.java that all pass (the two I gave you, and the two you wrote yourself), then you are ready for the next step.

Step 14: Adding the title attribute to UCSBCourse (TDD style)

Now, we are going to take this a step further: we are going to add an additional attribute, "title" to our UCSBCourse class, as in the "title" of a course, e.g.

We are going to do this using the "test driven development" approach (TDD).

Here are the detailed instructions:

Step 14a: Add a title parameter to all calls to the UCSBCourse constructor

Working in both UCSBCourseTester.java and UCSBCourse.java, add another parameter to the UCSBCourse constructor, as the third of the four parameters.

That is, the old constructor had three parameters, in this order:

• Department (a String), Course Number (a String) and units (an integer)

In the new version, it should have four parameters:

• Department (a String), Course Number (a String), Course Title (a String), and units (an integer)

For example, change this:

UCSBCourse cs56 = new UCSBCourse("CMPSC","56",4);    

to this:

UCSBCourse cs56 = new UCSBCourse("CMPSC","56","Advanced Applications Programming",4);    

Do this for all the constructor invocations. You won't be able to recompile yet, of course, because we also have to add the parameter to the constructor's definition in UCSBCourse.java—that's the next step.

Step 14b: Add a parameter to the constructor

Add a parameter to the constructor for UCSBCourse (in UCSBCourse.java) that corresponds to this new title parameter. You'll also need to add a private "data member" (i.e. an "attribute") to the class to store this title.

Be sure that in addition to changing the constructor code, you also change the Javadoc comment as appropriate to add this additional parameter.

Step 14c: Add a JUnit test for a method getTitle() to UCSBCourseTest.java

Following the model of test-driven development, we add a test before writing the code for the method.

Note:

• We will ONLY add this test to the UCSBCourseTest.java&mdash
• It is NOT necessary to add a test for this method to the old style UCSBCourseTester.java—we are so over that clumsy way of testing now that we have sleek modern JUnit to work with.

Follow the example of the JUnit tests you see already. If you want a more detailed explanation of how JUnit tests work, consult the links below (keep in mind you are using JUnit 4, not JUnit 3.8):

• JUnit
• http://junit.org
• http://junit.sourceforge.net/

Step 14d: Add a stub method for getTitle() to UCSBCourse.java

Your stub method should return something like "stub", or "this isn't the course title you're looking for".

Step 14e: Try "ant test" again

It should try to compile everything, and then run your new test, and the test should fail.

If you get compiler errors, fix those first. Then, once you see your test failing, you are ready for the final step...

Step 14f: Fix the method for getTitle() so that it works properly.

Now, make the test pass.

Once your test passes, you are ready to move on!

Step 15: final code walkthrough against rubric

Now, you are almost done. The last two steps are to:

• check your code to be sure you will maximize your grade, and
• execute the turnin command.

In this step, you are going to check your code. Check it against two things:

1. ALL OF THE INSTRUCTIONS IN THIS LAB ASSIGNMENT. Start over at the very first step. If you are working a pair, have one pair partner read through the instructions, and have the other pair partner check the code (or in the case of the javadoc, check both the code, and what appears on the web.)
2. ALL OF THE ITEMS IN THE GRADING RUBRIC. The grading rubric for this lab appears near the end of this file. It is the checklist that the TAs and instructor will use to determine your lab grade. Again, if working in a pair, divide up the responsibility (switching roles)—one person read the rubric items out loud, and the other person checks.

When everything is checked, you are ready to turnin your code.

Step 16: turnin step

First, cd into ~/cs56/lab01 and do:

ant clean

This will remove any files that don't need to be part of your turnin (i.e. files that can be generated from the source code.)

Then, cd into ~/cs56 (or you can use cd ..) and do this:

turnin lab01@cs56 lab01

This will turnin the entire contents of your lab01 directory, including both your .java files and your build.xml file.

And then you are finished with this lab. Congratulations!

Grading Rubric: Total Points: 300

Partial credit may be awarded for each step at the discretion of the TA/Instructor.

Mechanics

• (10 pts) Executing the turnin step on a directory called lab01
• (10 pts) Having three .java files named UCSBCourse.java and UCSBCourseTester.java and UCSBCourseTest.java and a build.xml file in your submission

Build.xml

• (10 pts) Creating a build.xml file (as specfied at step 2)
  • ant compile should do what it is supposed to do
• (10 pts) clean target present and works correctly (as specified at step 6, and additional material at step 11)
  • submitted build.xml has a clean target that gets rid of all .class files as well as the javadoc subdirectory.
  • ideally, after executing ant clean all that is left in your ~/cs56/lab01 directory is your .java files and your build.xml file
  • it's ok if there are emacs backup files laying around
• (10 pts) dependency between run and compile (see step 6)
• (10 pts) properties are present (see step 7, 8)
  • Properties that should be present: webRoot, webBaseURL, projectName, javadocDest, javadocURL
• (10 pts) javadoc target is present in build.xml (step 9)
• (10 pts) javadoc target works correctly and your javadoc appears on the web (step 10)
  • check http://www.cs.ucsb.edu/~username/cs56/lab01/javadoc to make sure the javadoc is present
• (10 pts) step 11 improvements to build.xml (cleaning up javadoc, adding debug information in .class)
• (10 pts) adding JUnit into the classpath (step 12a)
• (10 pts) add target for JUnit into build.xml (step 12b)
  • ant test should do what it is supposed to do
  • this implies that this line was fixed correctly in the test target: <include name="**/*Test.java"/>
• (10 pts) target for JUnit works correctly, and no compiler errors for JUnit code (because class path is correct) (Step 12)

UCSBCourseTest.java

• (20 pts) Two new tests that correspond to the ones that were in UCSBCourseTester.java from lab00
• (20 pts) Adding title to every call to the constructor
• (20 pts) Adding test for the getTitle() method
• (20 pts) Every method added has javadoc comments

UCSBCourse.java

• (20 pts) Adding attribute for title
• (20 pts) Adding parameter to constructor (and code to assign value to the attribute)
• (20 pts) Adding a getter that works properly
• (20 pts) Every method added, and every new parameter to a method has appropriate javadoc comments

General Good Practices

• (10 pts) Following Instructions
  • If there is anything that you should have done that was in the instructions but isn't already covered elsewhere in the grading rubric, these points are the ones that are "at risk" for those items.
• (10 pts) Coding Style
  • By this point in your programming career, you should know about things like using good variable names, indenting properly, factoring out common code into a subroutine, etc. Anything that is an obvious defect in your code is something that TAs have discretion to deduct points for, up to the amount specified for this item.

Due Date

You should do your best to complete this within the assigned lab time during week 2 of the quarter.

If that is not possible, then you should complete the assignment and execute the turnin command no later than 5pm Friday of week 3 of this quarter. This gives you one full week to seek help during office hours from both the instructor and the TAs, plus one additional lab period to ask the TAs for additional help.

Submissions turned in after that time are subject to receiving zero credit.