public ClassRosterDaoFileImpl(){
    roster_file = "roster.txt";
}
 
public ClassRosterDaoFileImpl(String rosterTextFile){
    roster_file = rosterTextFile;
}

Adding hashCode and equals to Student

To make testing easier, we implement the equals and hashCode methods for the Student object. This will allow us to easily compare two Student objects to see if the values of their fields match.

Both equals and hashCode are methods inherited from the Object class. The default implementation of equals simply compares the heap location of two Student references to see if they are pointing to the same place on the heap, equating whether or not they are literally the same object. While useful, during testing it would be more useful to have the method work similarly to the String's overloaded version, where when comparing two Students’ contents, if the same, those two Student objects would be considered equal.

We will only use the equals method for our tests. This requires that if two objects are equal, then the hashCode values for each object must also match. As such, we must also implement the hashCode method. We won't get into all the details here, but essentially, the hashCode of an object is a unit integer value that represents the state of that object. In short, two objects that are equal to one another must have the same hashCode value.

Luckily, NetBeans (and every other IDE) will generate these methods for us and will help ensure that they are implemented correctly. In fact, NetBeans won't let you generate one without the other.

Simply follow these steps to add equals and hashCode:

1. Open the Student class and right-click the class name to get a pop-up menu. Select the Insert Code option in the menu.
2. Select equals() and hashCode() from the list of options.
3. Select all four checkboxes in both sections. All the Student properties are important for this.
4. Click the Generate button.

You should end up with two methods that look similar to the ones in Listing 31.2. Make sure all the properties are accounted for in yours, but don't worry if the numbers are a little different. The numbers are autogenerated, and it is not as important that they match exactly with the ones in our example.

LISTING 31.2

Student's New equals and hashCode Methods

@Override
public int hashCode() {
    int hash = 7;
    hash = 89 * hash + Objects.hashCode(this.firstName);
    hash = 89 * hash + Objects.hashCode(this.lastName);
    hash = 89 * hash + Objects.hashCode(this.studentId);
    hash = 89 * hash + Objects.hashCode(this.cohort);
    return hash;
}
 
@Override
public boolean equals(Object obj) {
    if (this == obj) {
        return true;
    }
    if (obj == null) {
        return false;
    }
    if (getClass() != obj.getClass()) {
        return false;
    }
    final Student other = (Student) obj;
    if (!Objects.equals(this.firstName, other.firstName)) {
        return false;
    }
    if (!Objects.equals(this.lastName, other.lastName)) {
        return false;
    }
    if (!Objects.equals(this.studentId, other.studentId)) {
        return false;
    }
    if (!Objects.equals(this.cohort, other.cohort)) {
        return false;
    }
    return true;
}

Now that you have these methods, you can assert on whole Student objects to check their equality with another Student object.

Adding toString to Student

It is also recommended to add an overridden toString method to your Student class to help with test failure messages. This toString method is added mostly for convenience. Often in error messages, JUnit will print out information about the object that failed a test. It helps if that information is readable to us, but the default toString method only really serializes the object's class name and hashcode. Both are interesting pieces of information, but not often particularly usable. Overriding this method can allow us to print out all the object's property values instead, which can allow for much better insight into issues when reading test logs.

To add your new toString method, follow the same process we used earlier for adding the equals and hashcode methods. Right-click the Student class name and select Insert Code. From the menu, select toString to display the code generation dialog. From the dialog, select all the fields and then click the Generate button to add the code that will be similar to Listing 31.3.

LISTING 31.3

Example of Student's New toString Method

@Override
public String toString() {
    return "Student{" + "firstName=" + firstName + ", lastName=" + lastName + ", studentId=" + studentId + ", cohort=" + cohort + '}';
}

Creating the Test Class

Our next step is creating the JUnit test class that will hold our test suite for our DAO. To do this, we follow similar steps to the ones done in the stateless testing exercises.

1. In NetBeans’s Project view, right-click the ClassRosterDaoFileImpl class.
2. Select Tools, and then select Create/Update Tests.
3. Walk through the wizard to create a new JUnit class.
   • The name should look similar to classroster.dao.ClassRosterDaoFileImplTest.
   • Ensure that Test Packages is selected in the Location drop-down.
   • Generated Code Checkbox List should have everything selected.
   • Method Access Levels Checkbox List should have nothing selected.
   • Generated Comments Checkbox List should have nothing selected.
4. Click OK.

Once you complete the wizard, you should be left with a new Java class similar to Listing 31.4. This class is the shell of our new test suite, and we will be creating new tests to replace the testSomeMethod method with real tests.

LISTING 31.4

ClassRosterDaoFileImplTest

public class ClassRosterDaoFileImplTest {
 
    public ClassRosterDaoFileImplTest() {
    }
 
    @BeforeAll
    public static void setUpClass() {
    }
 
    @AfterAll
    public static void tearDownClass() {
    }
 
    @BeforeEach
    public void setUp() {
    }
 
    @AfterEach
    public void tearDown() {
    }
 
    @Test
    public void testSomeMethod() {
        fail("The test case is a prototype.");
    }
 
}

public class ClassRosterDaoFileImplTest {
 
    ClassRosterDao testDao;
 
    public ClassRosterDaoFileImplTest() {
    }
 
    @BeforeEach
    public void setUp() throws Exception{
        String testFile = "testroster.txt";
        // Create a new FileWriter for the test roster file 
        new FileWriter(testFile);
        testDao = new ClassRosterDaoFileImpl(testFile);
    }
}

Add Student

Let's look at the DAO interface method and comment, which is shown in Listing 31.6, before we get started on designing a test for this method.

LISTING 31.6

The DAO Interface Method and Comment

/**
 * Adds the given Student to the roster and associates it with the given
 * student id. If there is already a student associated with the given
 * student id it will return that student object, otherwise it will
 * return null.
 *
 * @param studentId id with which student is to be associated
 * @param student student to be added to the roster
 * @return the Student object previously associated with the given  
 * student id if it exists, null otherwise
 */
Student addStudent(String studentId, Student student)
     throws ClassRosterPersistenceException;

Reading through both the method and its JavaDoc comment, let's list some of the information we can gather about this method and its potential testing requirements. Here is what we know about addStudent:

• To call this method, we will need a studentId String and a Student object.
• After calling this method with those parameters, the student should now be stored within ClassRosterDaoFileImplTest and be associated with the given studentId.
• If there was no student in the DAO already with that studentId, the return should be null.
• However, if there was a student stored under that ID, then the previous Student associated will be returned.
• There is also a chance that this method could throw a ClassRosterPersistenceException, which implies it is touching a data store (we know it should be reading and writing to the file).

All this data is something we should already know, but it is always a good idea to double- and even triple-check your assumptions when beginning the testing process.

Looking at our gathered information, the first two bullet points are particularly important for our testing purposes. In this case, they focus on the fact that addStudent changes the state by adding a new or replacing an existing student within the DAO.

However, just the state change isn't the only thing we need to focus on. We need to also understand how to assert and prove that the state change happened correctly. In this case, we use other methods to measure the effect that this method call had on the state—the change of students stored within the DAO.

Remember, the ClassRosterDaoFileImplTest has three other methods: getStudent, getAllStudents, and removeStudent. Technically, each one of these could be used to verify the effect that calling the addStudent method has on the DAO, but getStudent is particularly well suited in that it allows us to simply retrieve the student from the DAO and examine it.

Get Student

Before we use it in a test, let's refresh ourselves with what getStudent does. Listing 31.7 presents the current code for getStudent.

We know the following things about getStudent:

• To call this method, we will need a studentId String.
• The return should be a Student object. In theory, this is a student previously stored under that ID.
• If there was no student in the DAO with that studentId, the return should be null.
• There is also a chance that this method could throw a ClassRosterPersistenceException, which again implies touching a persistent data store.

@Test
public void testAddGetStudent() throws Exception {
    // Create our method test inputs
    String studentId = "0001";
    Student student = new Student(studentId);
    student.setFirstName("Ada");
    student.setLastName("Lovelace");
    student.setCohort("Java-May-1845");
 
    //  Add the student to the DAO
    testDao.addStudent(studentId, student);
    // Get the student from the DAO
    Student retrievedStudent = testDao.getStudent(studentId);
 
    // Check that the data is equal
    assertEquals(student.getStudentId(),
                retrievedStudent.getStudentId(),
                "Checking student id.");
    assertEquals(student.getFirstName(),
                retrievedStudent.getFirstName(),
                "Checking student first name.");
    assertEquals(student.getLastName(), 
                retrievedStudent.getLastName(),
                "Checking student last name.");
    assertEquals(student.getCohort(), 
                retrievedStudent.getCohort(),
                "Checking student cohort.");
}

Get All Students

Let's look at the DAO interface method and comment before we get started on designing a test for the getAllStudents method. This is shown in Listing 31.9.

LISTING 31.9

The getAllStudents Interface Method and Comments

/**
 * Returns a List of all Students on the roster.
 *
 * @return Student List containing all students on the roster.
 */
List<Student> getAllStudents()
     throws ClassRosterPersistenceException;

This is an easier method to consider. It takes in no parameters and simply returns a list of students within the DAO. To properly test this method, we're going to have to use it alongside addStudent and maybe removeStudent to change what is contained within the list.

@Test
public void testAddGetAllStudents() throws Exception {
    // Create our first student
    Student firstStudent = new Student("0001");
    firstStudent.setFirstName("Ada");
    firstStudent.setLastName("Lovelace");
    firstStudent.setCohort("Java-May-1845");
 
    // Create our second student
    Student secondStudent = new Student("0002");
    secondStudent.setFirstName("Charles");
    secondStudent.setLastName("Babbage");
    secondStudent.setCohort(".NET-May-1845");
 
    // Add both our students to the DAO
    testDao.addStudent(firstStudent.getStudentId(), firstStudent);
    testDao.addStudent(secondStudent.getStudentId(), secondStudent);
 
    // Retrieve the list of all students within the DAO
    List<Student> allStudents = testDao.getAllStudents();
 
    // First check the general contents of the list
    assertNotNull(allStudents, "The list of students must not be null.");
    assertEquals(2, allStudents.size(),"The list of students should have 2 students.");
 
    // Then the specifics
    assertTrue(testDao.getAllStudents().contains(firstStudent),
                "The list of students should include Ada.");
    assertTrue(testDao.getAllStudents().contains(secondStudent),
            "The list of students should include Charles.");
 
}

Remove Student

Let's look at the DAO interface method and comment for removing a student before we get started on designing a test for this method. Listing 31.11 shows the removeStudent interface method.

LISTING 31.11

The removeStudent Interface Method and Comments

/**
 * Removes from the roster the student associated with the given id.
 * Returns the student object that is being removed or null if
 * there is no student associated with the given id
 *
 * @param studentId id of student to be removed
 * @return Student object that was removed or null if no student
 * was associated with the given student id
 */
Student removeStudent(String studentId);

We know the following things about removeStudent:

• To call this method, we will need a studentId String.
• The return should be a Student object. In theory, this is a student that was previously stored under that ID.
• If there was no student in the DAO with that studentId, the return should be null.
• The state effect of this on the DAO is that the returned student should no longer be within the DAO.
• There is another mention of a ClassRosterPersistenceException, which implies more persistent data storage.

@Test
public void testRemoveStudent() throws Exception {
    // Create two new students
    Student firstStudent = new Student("0001");
    firstStudent.setFirstName("Ada");
    firstStudent.setLastName("Lovelace");
    firstStudent.setCohort("Java-May-1945");
 
    Student secondStudent = new Student("0002");
    secondStudent.setFirstName("Charles");
    secondStudent.setLastName("Babbage");
    secondStudent.setCohort(".NET-May-1945");
 
    // Add both to the DAO
    testDao.addStudent(firstStudent.getStudentId(), firstStudent);
    testDao.addStudent(secondStudent.getStudentId(), secondStudent);
 
    // remove the first student - Ada
    Student removedStudent = testDao.removeStudent(firstStudent.getStudentId());
 
    // Check that the correct object was removed.
    assertEquals(removedStudent, firstStudent, "The removed student should be Ada.");
 
    // Getall the students
    List<Student> allStudents = testDao.getAllStudents();
 
    // First check the general contents of the list
    assertNotNull( allStudents, "All students list should be not null.");
    assertEquals( 1, allStudents.size(), "All students should only have 1 student.");
 
    // Then the specifics
    assertFalse( allStudents.contains(firstStudent), 
                 "All students should NOT include Ada.");
    assertTrue( allStudents.contains(secondStudent), 
                "All students should NOT include Charles.");    
 
    // Remove the second student
    removedStudent = testDao.removeStudent(secondStudent.getStudentId());
    // Check that the correct object was removed.
    assertEquals( removedStudent, secondStudent, 
                  "The removed student should be Charles.");
 
    // retrieve all of the students again and check the list.
    allStudents = testDao.getAllStudents();
 
    // Check the contents of the list - it should be empty
    assertTrue( allStudents.isEmpty(), 
                "The retrieved list of students should be empty.");
 
    // Try to get both students by their old id. They should be null.
    Student retrievedStudent = testDao.getStudent(firstStudent.getStudentId());
    assertNull(retrievedStudent, "Ada was removed, should be null.");
 
    retrievedStudent = testDao.getStudent(secondStudent.getStudentId());
    assertNull(retrievedStudent, "Charles was removed, should be null.");
 
}

Planning the Test Design

The main purpose of the unit test suite for the service layer is to test that the business rules are being applied properly. For completeness, we will also test the pass-through methods of the service layer. We will test these business rules:

• Creation of a Student object with an existing student ID is prohibited.
• All fields on the Student object must have nonempty values.

These business rules are enforced in the createStudent method of the DAO. We will need three test cases:

• Create valid student. All fields have values, and the student does not have an existing student ID.
• Create a student with an existing student ID.
• Create a student with one or more empty field values.

We will also implement tests for getAllStudents, getStudent, and removeStudent. These tests will be similar to the tests we created for the matching DAO methods in a previous step.

Creating the Test Class

You should remember this step from our DAOImpl testing step. We will create a JUnit test class that will hold our test suite for our service layer. Do the following:

1. In the NetBeans Project view, right-click the ServiceLayerImpl class.
2. Select Tools, and then select Create/Update Tests.
3. Walk through the wizard to create a new JUnit class.
   • The name should look similar to classroster.service.ClassRosterServiceLayerImplTest.
   • Ensure that Test Packages is selected in the Location drop-down.
   • Generated Code Checkbox List should have everything selected.
   • Method Access Levels Checkbox List should have nothing selected.
   • Generated Comments Checkbox List should have nothing selected.
4. Once these steps are finished, click the OK button.

Completing the wizard should leave you with a new Java test class, as shown in Listing 31.13, where we will write our service layer test suite.

LISTING 31.13

ClassRosterServiceLayerImplTest

public class ClassRosterServiceLayerImplTest {
 
    public ClassRosterServiceLayerImplTest() {
    }
 
    @BeforeAll
    public static void setUpClass() {
    }
 
    @AfterAll
    public static void tearDownClass() {
    }
 
    @BeforeEach
    public void setUp() {
    }
 
    @AfterEach
    public void tearDown() {
    }
 
    @Test
    public void testSomeMethod() {
        fail("The test case is a prototype.");
    }
}

Creating the DAO Stubs

The service layer is not responsible for storing or retrieving Student objects. That is the job of the DAO. This means we don't have to (or want to) test the actual persistence of Student objects in this test suite. We only want to test the business rules and the integration between the service layer and the DAO.

Given this fact, we can use stubbed versions of our DAOs to test the functionality of the service layer. Since we are programming to interfaces and using constructor-based dependency injection, it will be easy to use the stubbed versions of the DAOs instead of the file-based implementations.

A stubbed version of a component simply returns canned data for any method call. We can set up a stubbed version of a component to act just about any way we want or need it to. Let's take a look at the stubbed implementation of our DAOs.

public class ClassRosterAuditDaoStubImpl implements ClassRosterAuditDao {
 
    @Override
    public void writeAuditEntry(String entry) throws ClassRosterPersistenceException {
        //do nothing . . .
    }
}

public class ClassRosterDaoStubImpl implements ClassRosterDao {
 
    public Student onlyStudent;
 
    public ClassRosterDaoStubImpl() {
    onlyStudent = new Student("0001");
        onlyStudent.setFirstName("Ada");
        onlyStudent.setLastName("Lovelace");
        onlyStudent.setCohort("Java-May-1845");
    }
 
    public ClassRosterDaoStubImpl(Student testStudent){
         this.onlyStudent = testStudent;
     }
 
    @Override
    public Student addStudent(String studentId, Student student)
                  throws ClassRosterPersistenceException {
        if (studentId.equals(onlyStudent.getStudentId())) {
            return onlyStudent;
        } else {
            return null;
        }
    }
 
    @Override
    public List<Student> getAllStudents()
                 throws ClassRosterPersistenceException {
        List<Student> studentList = new ArrayList<>();
        studentList.add(onlyStudent);
        return studentList;
    }
 
    @Override
    public Student getStudent(String studentId)
                throws ClassRosterPersistenceException {
        if (studentId.equals(onlyStudent.getStudentId())) {
            return onlyStudent;
        } else {
            return null;
        }       
    }
 
    @Override
    public Student removeStudent(String studentId)
                throws ClassRosterPersistenceException {
        if (studentId.equals(onlyStudent.getStudentId())) {
            return onlyStudent;
        } else {
            return null;
        }
    }   
}

Test Setup

By using stubbed DAOs for these tests, we have essentially defined the state of our test system. Since the DAOs are the properties that belong to our service layer, their state represents the state of our service layer. That means if we can start these DAOs in a good state, so will our service layer. Since our stubs start in a predefined state, we will begin testing our service layer with the assumption that it contains a Class Roster DAO with exactly one student.

Although we don't have to do any work to put our code in a known good state, we do have to create the service layer object and wire in our stub DAOs. This code is similar to the code we have in the App class of the Class Roster application. Update the top of your ClassRosterServiceLayerImplTest with the setup in Listing 31.16.

LISTING 31.16

Create the Service Layer Object and Wire a Stub DAO

private ClassRosterServiceLayer service;
 
public ClassRosterServiceLayerImplTest() {
    ClassRosterDao dao = new ClassRosterDaoStubImpl();
    ClassRosterAuditDao auditDao = new ClassRosterAuditDaoStubImpl();
 
    service = new ClassRosterServiceLayerImpl(dao, auditDao);
}

Test Implementation

Finally, we will look at our test implementations. These include testCreateValidStudent, testCreateStudentDuplicateId, testGetAllStudents, testGetStudent, and testRemoveStudent.

@Test
public void testCreateValidStudent() {

    // ARRANGE
    Student student = new Student("0002");
    student.setFirstName("Charles");
    student.setLastName("Babbage");
    student.setCohort(".NET-May-1845");
    // ACT
    try {
        service.createStudent(student);
    } catch (ClassRosterDuplicateIdException
        | ClassRosterDataValidationException
            | ClassRosterPersistenceException e) {
    // ASSERT
        fail("Student was valid. No exception should have been thrown.");
    }
}

@Test
public void testCreateDuplicateIdStudent() {
    // ARRANGE
    Student student = new Student("0001");
    student.setFirstName("Charles");
    student.setLastName("Babbage");
    student.setCohort(".NET-May-1845");
 
    // ACT
    try {
        service.createStudent(student);
        fail("Expected DupeId Exception was not thrown.");
    } catch (ClassRosterDataValidationException
            | ClassRosterPersistenceException e) {
    // ASSERT
        fail("Incorrect exception was thrown.");
    } catch (ClassRosterDuplicateIdException e){
        return;
    }
}

@Test
public void testCreateStudentInvalidData() throws Exception {
    // ARRANGE
    Student student = new Student("0002");
    student.setFirstName("");
    student.setLastName("Babbage");
    student.setCohort(".NET-May-1845");
 
    // ACT
    try {
        service.createStudent(student);
        fail("Expected ValidationException was not thrown.");
    } catch (ClassRosterDuplicateIdException
            | ClassRosterPersistenceException e) {
    // ASSERT
        fail("Incorrect exception was thrown.");
    } catch (ClassRosterDataValidationException e){
        return;
    }  
}

@Test
public void testGetAllStudents() throws Exception {
    // ARRANGE
    Student testClone = new Student("0001");
        testClone.setFirstName("Ada");
        testClone.setLastName("Lovelace");
        testClone.setCohort("Java-May-1845");
 
    // ACT & ASSERT
    assertEquals( 1, service.getAllStudents().size(), 
                                   "Should only have one student.");
    assertTrue( service.getAllStudents().contains(testClone),
                              "The one student should be Ada.");
}

@Test
public void testGetStudent() throws Exception {
    // ARRANGE
    Student testClone = new Student("0001");
        testClone.setFirstName("Ada");
        testClone.setLastName("Lovelace");
        testClone.setCohort("Java-May-1845");
 
    // ACT & ASSERT
    Student shouldBeAda = service.getStudent("0001");
    assertNotNull(shouldBeAda, "Getting 0001 should be not null.");
    assertEquals( testClone, shouldBeAda,
                             "Student stored under 0001 should be Ada.");
 
    Student shouldBeNull = service.getStudent("0042");    
    assertNull( shouldBeNull, "Getting 0042 should be null.");
 
}

@Test
public void testRemoveStudent() throws Exception {
    // ARRANGE
    Student testClone = new Student("0001");
        testClone.setFirstName("Ada");
        testClone.setLastName("Lovelace");
        testClone.setCohort("Java-May-1845");
 
    // ACT & ASSERT
    Student shouldBeAda = service.removeStudent("0001");
    assertNotNull( shouldBeAda, "Removing 0001 should be not null.");
    assertEquals( testClone, shouldBeAda, "Student removed from 0001 should be Ada.");
 
    Student shouldBeNull = service.removeStudent("0042");    
    assertNull( shouldBeNull, "Removing 0042 should be null.");
 
}

Exercise 1: Testing the Address Book App

Design and implement a complete set of unit tests for the DAO of the Address Book application that you created in Lesson 27. Use the lesson notes as a guide and pattern your test suite after the test suite created in the Class Roster unit test code-along earlier in this lesson.

Exercise 2: Testing the DVD Library

Design and implement a complete set of unit tests for the DAO of the DVD Library application that you created in Lesson 27. Use the information from this lesson as a guide and pattern your test suite after the test suite created in the Class Roster application.