In this lab, you will examine a JUnit test for my two library classes
that implement the Stack interface (ArrayStack
and LinkedStack) and learn how to write, run, and interpret your own
To start, please download the
JUnit Stack Demo.
Load this into Eclipse as a project folder.
It is set up automatically to include the junit-4.1.jar library
contained in this project, which contains the JUnit library classes.
In general, see the Java/Eclipse-related files on the page reachable by the Online Resources link in the course index. The Download: Course JUnit 4.1 (all files, including .jar and Javadoc) link there contains this .jar file, as well as the complete documentation for using this class (although this lab will cover all that you need to know for this course) You might want to put this .jar file in your workspace and then add it to your standard libraries in the JRE (as you did with the cs15-1xx.library.jar file).
Note: When you look at the StackTest.java file in Eclipse, ignore all the warnings on the collection class operations; when we learn about generic classes, we will see how to correct these warnings: they are not errors so the program will still run.
Generally, for systems comprising many classes, there are two kinds of testing: unit testing and integration testing. Unit testing, which is done first, is concerned with testing classes individually; integration testing is concerned with testing multiple classes (up to testing complete programs). The former deals with the correctness of each class (e.g., constructors establish, and methods sustain, the data invariants: methods change instance variables appropriately and return correct values); the latter with how the classes use each other. For more information see the Testing section in the lecture on Program Construction and Debugging
Extreme Programming (XP) puts a heavy emphasis on unit testing. It dictates that before writing a class, someone (the programmer him-/herself, or a special "test engineer") should write code that will test the class. Aside:In fact, Microsoft pairs programmers and testers: they realize, psychologically, that programmers often make poor testers: they have little incentive to find that they have written buggy code. Bugs are more likely to be uncovered by someone else, who has no vested interest in writing the code. The testing code can be finished immediately after the specifications for the class are finalized. These tests should be extensive, such that if a class passes the tests, it is ready to move to integration testing.
Often in this course we write just interactive drivers to do our unit testing. These drivers give us the flexibility of testing arbitrary sequences of method calls to an object constructed from the class we are testing. It is certainly useful to use such drivers for exploratory purposes, but there is also a strong case to be made for developing more automated testing.
Fundamentally, software changes: we are always improving code (by correcting it, making it run faster, or by enhancing its functionality). When we change code, it is easy to introduce new errors. By writing automated tests, when we update code, we can easily add new tests and ensure that all the old tests still produce correct results. Retesting on updated software is called Regression Testing.
Over the last year or two (the time I have been playing with JUnit) I have become a convert. With alarming regularity, I find bugs in classes that I have been using for years, when I go to the trouble of writing JUnit tests for them. If these test were written first, as XP dictates, the bugs would have been spotted and corrected much earlier.
Reality check. The purspose of most educational courses is to introduce you to new ideas and teach you how and when to apply them, not necessarily to make you use them repeatedly. So, the purpose of this lab is to ensure you are familiar with debugging with JUnit testing and writing your own JUnit tests. Later in the course, I will distribute JUnit tests to help you debug your projects: tests you could write if you had the time. If you do write your own JUnit tests, you are welcome to share them freely with your classmates. Ultimately whether you write your own JUnit tests in the future (in this class, others, or in jobs) is up to your discression. Finallly, it is easy to collaborate with others when writing JUnit tests: you can divide up all the aspects of this task and then reassemble the resulting code easily, because each test is run independently from the others.
|JUnit Testing of Stacks||
In this section, we will look at the JUnit test for classes implemeneting the
Stack infterface: ArrayStack and LinkedStack, both
already in the class library.
Of course, this class is correct (I hope:), but we can still use it to explore
JUnit testing: by introducing some errors, we can also see how such errors
are detected and reported by JUnit.
So, let's start by opening that project in Eclipse.
Let's look through the StackTest.java file and note the following.
|A JUnit Test for Sequential||
In this section, we will look at how to use Eclipse to help you automatically
generate a JUnit test for a class.
You might immediately ask, "But aren't we supposed to create JUnit tests
BEFORE we write the class."
Yes, you are: after the class is specified but before you write it.
In fact, after you specify a class you should be able to "boiler-plate" in
all its constructors and methods, with the right prototypes.
You need only these boiler-plated methods to generate the JUnit test.
So, if two groups were working together on a class, one group can take the
specification (written as a boiler-plated class) and go off to implement the
class (by filling in the constructors and methods); the other can take the
specification and go off to implement the JUnit test.
In this lab, you will generate a JUnit test for your Sequence class (from Quiz #5). So, first download your code and load it as a project file into Eclipse. Here you will also need to download the JUnit 4.1 information (see the Online Resources link), unzip it, and then build a path to the junit-4.1.jar file. You might want to put this file in your workspace and then alter the JRE to always include that library (as you did with the cs15-1xx.library.jar file).
Next we will create a JUnit test class for Sequential
For this lab, try to write a test for remove (which is the hardest method to get right/coordinated with the others via data invariants). Think of a few tests and how to implement theim; then code them in the testRemove method, and see if your code works on them correctly. Let me know if you can write a test that exposes a bug in your code.