Question

I’m trying to get into Unit testing for the obvious positives it introduces, and I’m trying to write a Unit test for a class I wrote the other day. (I know this is the opposite to TDD, please bear with me)

My class, Image, is used in conjunction with some others for image manipulation.

Image essentially wraps a GD image resource and stores data along with it. For example, an instance of Image will always contain it’s current state, i.e. its new width/height if resized, the original image data, etc.

The Image class also contains methods for,

• Creating itself from a file, string data, or URL, e.g. $image->loadFromPath()
• Creating a new GD image resource from the properties of the current Image instance, e.g. for image resizing to maintain background transparency, etc.
• Cloning the GD image resource for use in the manipulation classes

What I’m struggling with is how to Unit test this class properly with PHPUnit. I’ve done some reading and I have a few conflicting ideas on how to approach it and I don’t know what’s right. Do I,

1. Write a test for each method of the class. I read somewhere that I should test each and every method. However, some of the methods run others (rightly so may I add), so you then have a chain of dependency. But I also read that each Unit test should be independent from the other. So what do I do if this is the case?
2. Write each test as a usage route of the class. I also read somewhere that each test should instead represent 1 path/usage route you can take with the class. Therefore if you cover every usage, you’ll ultimately get complete code coverage.

So, which of these is correct, if any?

Answer 1

Unit tests should be written to evaluate the public interface of a class. Your test case should use the class as you intend it to be used in your program. The idea here is to test the behavior (either expected, unexpected, or edge conditions) of the class.

Both ideas you posted are correct. In theory, you should have enough test cases (routes through your code) that all your methods in the class are run.

As was mentioned, 100% test coverage is a nice goal, but not always realistic.

Also, in the case of GD, be careful about writing unit tests that test GD’s functionality (it’s already been tested, you don’t need to waste time testing it again). I would read up on using PHPUnit’s mocks and stubs (and mocking the filesystem) in the PHPUnit manual.

Here’s what an example test might look like:

public function testImageIsResized()
{
    $image = new Image();
    $image->loadFromPath('some/path');
    $image->resize(200, 300);
    $this->assertEquals(200, $image->getWidth());
    $this->assertEquals(300, $image->getHeight());
}

Now, depending on the expected behavior of the image class, this test might pass without issue, or it might fail because it was expecting the new dimensions to be proportionally constrained to the original image dimensions. But we did not explicitly call the internal method that checks for that constraint in the test itself.