Reputation: 4830
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?
Upvotes: 13
Views: 3226
Reputation: 8294
Stephen Melrose said:
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
Test independence isn't about not testing the same code twice, it's about whether the result (or lack of result) of one test affects the result of another. If your first test inserts some data and then fails before it can remove that data, your second test might get different results than expected. Ideally you should be able to run your tests in a random order, or run some and not others.
Upvotes: 0
Reputation: 17322
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.
Upvotes: 9
Reputation: 316939
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.
Upvotes: 5