Agile Javaв„ў: Crafting Code with Test-Driven Development
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 somethingnot 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. |