FAQ: Unit Testing

Use other means to check the effect of the method. E.g., if you are testing a deleteFile(fileName) method, you could do something like this.

deleteFile(fileName);
assertFalse(isFileExists(fileName));

In addition, you can refactor to make methods return values. For example, consider the following method.

void display() {
    // for each line in file
         // display line
}

It can be refactored like this:

void display(){
    String content = getFileContent(fileName);
    print(content);
}

Now, you can unit test getFileContent(fileName) method. There is no need to unit test display() method because most of it’s logic is in getFileContent(fileName) that is already unit tested.

Some of your methods returns the status of the method execution as a string. Just checking the return message of such methods is not enough if the command is expected to change the state of the data. You can use techniques used for testing void methods (given above) to check the correct execution of the method, in addition to checking the status message.

For now, make them public. In Java, there is a way to access private methods using reflection. Alternatively, we can omit testing private methods because only public methods are exposed to others. If public methods are working correctly, private methods must be working correctly too.
A more extensive discussion of this issue can be found here.

That part is hard to test. Separate the ‘reading user command’ part from the rest and test the rest. See CityConnectTest.java(in the Schedule page) for an example.

Similar to the previous question. Separate the generating of the text to display from displaying the text. The former is the more complicated part which should be unit tested.

String result = executeCommand(command); //unit test this method
displayToUser(result); //simple, no need to unit test

If your software is completely text based, you can use the I/O redirection method covered in lecture 1 to test the software including the input and output.

TextBuddy.exe < input.txt > output.txt
FC output.txt expected.txt

Yes, it is acceptable. You can use methods that are already unit-tested to test other methods. e.g., you can use clear() and add() methods when testing the sort() method.

Note: This is not strictly ‘unit testing’ as we are not testing the unit in complete isolation from the rest of the code, but it is acceptable because other units are already tested and are under your control too.

Automated tests are not just to check if the code works NOW, but they help to ensure it keeps working FOREVER. Their main purpose is regression testing.

Writing tests first makes you write more testable code. If you write the functional code first, you often find such code is harder to test. Furthermore, it encourages you to think WHAT the code should do before you figure out HOW the code should do it.