| Deliverables | ||
|---|---|---|
 | Chapter 1. Foundations |  |
| Deliverables | ||
|---|---|---|
| | Chapter 1. Foundations | |
Each chapter defines the classes to be built and the unit testing that is expected. A third deliverable is merely implied. The purpose of each chapter is to write the source files for one or more classes, the source files for one or more unit tests, and assure that a minimal set of API documentation is available.
Source Files. The source files are the most important deliverable. In effect, this is the working application program. Generally, you will be running this application from within your Integrated Development Environment (IDE). You may want to create a stand-alone program.
In the case of Java, we might also deliver the collection of class files. Additionally, we might bundle the class files into an executable JAR file. The source is the principle deliverable; anyone should be able to produce class and JAR files using readily available tools.
In the case of Python, it's the packages of
.py files. There really isn't much more to deliver.
The interested student might want to look at the Python
distutils and setuptools
to create a distribution kit, or possibly a Python
egg file.
Unit Test Files. The deliverables section of each chapter summarizes the unit testing that is expected, in addition to the classes to be built. We feel that unit testing is a critical skill, and emphasize it throughout the inividual exercises. We don't endorse a particular technology for implementing the unit tests. There are several approaches to unit testing that are in common use.
Formal Unit Tests. For formal testing of some class, X,
we create a separate class, TestX, which
creates instances of X and exercises those
instances to be sure they work. In Java, this is often done with
JUnit. In Python, the
unittest module is the mechanism for doing
formal unit tests. Additionally, many Python developers also use
the doctest module to assure that the
sample code in the docstrings is actually correct. We cover these
technologies in the appendices.
Informal Unit Tests. This is often done by include a main program in the class definition file. We'll show two examples of this. By following the standard unit test naming conventions, these informal tests can be easily upgraded to more formal JUnit or PyUnit tests.
In Python, an informal is done by including the following block of
code section in a module file. Each test method must have a name that
starts with “test” to be compatible with the Python
PyUnit module.
Example 1.2. Informal Python Unit Test
def testX():
test procedure X goes here
def testY():
test procedure Y goes here
if __name__ == "__main__":
testX()
testY()
In Java, this is done by putting public static void main(String[] args); in the class source file. Each test method must have
a name that starts with “test” to be compatible with the
Java JUnit package.
Example 1.3. Informal Java Unit Test
class SomeClass {
public static void main( String[] args ) {
SomeClass x= new SomeClass();
x.testX();
x.testY();
}
public void testX() {
test procedure X goes here
}
public void testY() {
test procedure Y goes here
}
}
Documentation. The job isn't over until the paperwork is done. In the case of Java and Python, the internal documentation is generally built from specially formatted blocks of comments within the source itself. Java programmers can use the javadoc tool to create documentation from the program source. Python programmers can use Epydoc to create similar documentation.
| |  | |
| Methodology, Technique and Process |  | Part I. Roulette |