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,
$image->loadFromPath()
Image
instance, e.g. for image resizing to maintain background transparency, etc.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,
So, which of these is correct, if any?
A typical unit test contains 3 phases: First, it initializes a small piece of an application it wants to test (also known as the system under test, or SUT), then it applies some stimulus to the system under test (usually by calling a method on it), and finally, it observes the resulting behavior.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With