Crafting Java Code with Test-Driven Development: the Basics
- CourseSession
- Enrolling Students
- int
- Initialization
- Default Constructors
- Suites
- The SDK and java.util.ArrayList
- Adding Objects
- Incremental Refactoring
- Objects in Memory
- Packages and the import Statement
- The java.lang Package
- The Default Package and the package Statement
- The setUp Method
- More Refactoring
- Class Constants
- Dates
- Overloaded Constructors
- Deprecation Warnings
- Refactoring
- Creating Dates with Calendar
- Comments
- Javadoc Comments
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this lesson you will:
- use the numeric type int to count the number of students
- use the Java collection class java.util.ArrayList to store many students
- understand default constructors
- learn how to use the J2SE API documentation to understand how to use java.util.ArrayList
- restrict the java.util.ArrayList collection to contain only Student objects
- create a TestSuite to test more than one class
- learn about packages and the import statement
- understand how to define and use class constants
- use date and calendar classes from the system library
- learn the various types of comments that Java allows
- generate API documentation for your code with javadoc
CourseSession
 |
Schools have courses, such as Math 101 and Engl 200, that are taught every semester. Basic course information, such as the department, the number, the number of credits, and the description of the course, generally remains the same from semester to semester. |
|
A course session represents a specific occurrence of a course. A course session stores the dates it will be held and the person teaching it, among other things. It also must retain an enrollment, or list of students, for the course. |
You will define a CourseSession class that captures both the basic course information and the enrollment in the session. As long as you only need to work with the CourseSession objects for a single semester, no two CourseSessions should need to refer to the same course. Once two CourseSession objects must exist for the same course, having the basic course information stored in both CourseSession objects is redundant. For now, multiple sessions is not a consideration; later you will clean up the design to support multiple sessions for a single course.
Create CourseSessionTest.java. Within it, write a test named testCreate. Like the testCreate method in StudentTest, this test method will demonstrate how you create CourseSession objects. A creation test is always a good place to get a handle on what an object looks like just after it's been created.
public class CourseSessionTest extends junit.framework.TestCase {
public void testCreate() {
CourseSession session = new CourseSession("ENGL", "101");
assertEquals("ENGL", session.getDepartment());
assertEquals("101", session.getNumber());
}
}
The test shows that a CourseSession can be created with a course department and number. The test also ensures that the department and number are stored correctly in the CourseSession object.
To get the test to pass, code CourseSession like this:
class CourseSession {
private String department;
private String number;
CourseSession(String department, String number) {
this.department = department;
this.number = number;
}
String getDepartment() {
return department;
}
String getNumber() {
return number;
}
}
So far you've created a Student class that stores student data and a Course-Session class that stores course data. Both classes provide "getter" methods to allow other objects to retrieve the data.
However, data classes such as Student and CourseSession aren't terribly interesting. If all there was to object-oriented development was storing data and retrieving it, systems wouldn't be very useful. They also wouldn't be object-oriented. Remember that object-oriented systems are about modeling behavior. That behavior is effected by sending messages to objects to get them to do something—not to ask them for data.
But, you've got to start somewhere! Plus, you wouldn't be able to write assertions in your test if you weren't able to ask objects what they look like.