No collaboration is allowed on this program assignment. Your program must be an individual and original effort. Except for any situations explicitly identified in this assignment, if any, you may only receive help from your instructor or the tutors provided by the Computer Science Department. See the Syllabus for the significant consequences for disallowed collaboration and/or plagiarism.
ErrataNone so far - updates and corrections, if any, will show up here (be sure to refresh this page as necessary).
Due Date and Submission InstructionsSubmit the following file(s) on one of the CSL servers using handin as follows:
file(s): SUnit.java
touser: eaugusti
assignment/subdirectory: 102-program01a
Unit testing and Test Driven Development are widely used techniques to help ensure code quality. They can be especially helpful to beginning programmers because their use encourages and facilitates incremental development. Incremental development helps you learn-as-you-go and can minimize confusion, bugs, and the amount of code that needs to be rewritten. While these techniques may not save time, they have been shown to improve code quality when employed by experienced professionals. It is my belief, when used correctly, their use will save most beginning programmers much time and frustration, and contribute to a deeper understanding of the process of software development.
There are many unit
testing frameworks already in existence. They tend to be rich,
complicated environments that can easily overwhelm beginning
programmers and distract attention away from the more fundamental
skills that need to be mastered first. This assignment attempts to
solve that conundrum by having you write a small, but useful, subset of
unit testing functions. By writing them yourself you will have a deeper
understanding of what they are doing and how they work. Also, because
they are relatively simple, they are serve as excellent place to start
learning Object Oriented Programming techniques! This assignment is modeled after a small subset of methods found in the JUnit framework.
Unit testing is not really an "object oriented" problem but, since this class is an OOP class and we are using Java, we'll have to make it fit. Normally I'd would avoid problems using the static key word as long as possible but, due to the nature of the problem, we are going to dive in head first! In Java methods (a.k.a. functions) can be static. The nice thing about static methods is they can be called without having to construct an object. The only restriction on static methods is that can only use static data and local variables (not instance variables). This is not a problem for us since we don't need any other type of data for our unit testing methods. When writing static methods you simply include the static keyword in the method declaration as follows:
public class SUnit
{
// Class variables here - syntax shown below.
public static void assertEquals(long expect, long actual)
{
// Stuff not shown...
}
}
The SUnit class will keep track of how many tests have been run and how
many of them detected errors. This means it will need some variables
that live for the life of the program and not just during a single
method call. This means local variables will not sufficient. Normally
we would declare instance variables
(variables declared in a class and outside of a method. However, static
methods can't access instance variables because no instance (object)
was created and, therefore, they don't exist! The solution is to
declare class variables. A class variable
belongs to the class and is shared by all instances of the class and it
exists for the life of the program. It is very much like a global
variable in C (if you know what that is). Fortunately, class variables
can be accessed by static methods - perfect for out needs. Class
variables are declared in a class and outside of a method and include
the static keyword in the declaration. Here is an example of how you
would declare a class variable in SUnit:
Calling static methods is straightforward in Java. Since a static method belongs to the class you simple call it as follows:
Finally, you will be making use of the Java Standard Library's Throwable class, specifically it's printStackTrace
method when reporting errors. To use the method you must first
construct a Throwable object and then call it on the object instance
you just created. The Throwable class has a constructor that
accepts a message - this is how you will provide the exact message
specified later in this assignment. Here is an example of how you could
construct a Throwable object and call the printStackTrace method:
To receive full credit your source code must meet the Programming Guidelines.
To
receive any credit your solution must pass all test of the
provided
test driver (link and instruction provided below) when compiled and run
on any of the CSL servers.
Implement a class called SUnit to this
specification. Your solution must only have the public methods
specified in the specification. Note that there is no main and no explicit (written) constructor.
You
may only use two private static int class variables, one to keep track
of how many assert methods are called and the other to keep track of
how many assert methods reported a failure. No other data fields are allowed in the class. You may use as many local variables as you deem necessary.
Develop incrementally, one method at a time, testing as you go. The methods are very similar so developing and testing one well and then using it as a model for the others will be both more efficient and more pleasant.
Do not use the provided test driver (provided on the first due date for the assignment, not before) until your solution is complete and you believe it is correct.
Using the save-as
feature of your browser, not
cut-and-paste, save SUnitTest.java in
the same directory as your SUnit.java file. Note that SUnitTest.java will be published on the morning of the first due date - it is not published earlier to encourage you to develop your own tests!
Compile both SUnitTest.java and SUnit.java and run SUnitTest (see How to Compile and Run From the Command Line, as necessary). Remember that your code will be graded on one of the CSL servers so, to avoid unpleasant grading surprises, be sure to test on any one of those machines at least once after all changes and just before handing in!