PHPUnit Test Question - How to Unit test my class

Question

Hi,

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

You can use the covers annotation to specify if a test covers multiple methods. So if one of your methods calls another method, you can simply add the annotation to the test's docblock and it will be added to your code coverage statistics, e.g.

/**
 * @test
 * @covers MyClass::something()
 * @covers MyClass::_somethingElse()
 */
public function somethingWorksAsExpected()
{
    $this->assertSame($expected, $this->testObject->something());
}

For personal projects, 100% Code coverage is fine. However, I've seen talks at conferences where 100% are doubted to be necessary. Despite all the benefits, tests take time to write and in a budgeted project it might be sufficient to just test 80/20 and leave out uncritical low priority features of your app.

As for how to test your class, have a look at the chapter on Behaviour Driven Development in the PHPUnit Manual. In your case, I'd test the functionality you described in your question.

Answer 2

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.