Unit Separation

Question

This question is related to PHPUnit, although it should be a global xUnit design question.

I am writing a Unit test case for the Image class.

One of the methods of this class is setBackgroundColor() .

There are 4 different behaviors to check for this method,

• Trying to set an invalid background color. Several invalid parameters will be checked.
• Trying to set a valid background color using a short RGB array, for example. array(255,255,255)
• Trying to set a valid background color using a standard RGB array, for example. array('red' => 255, 'green' => 255, 'blue' => 255) (this is the output format of the GD function imagecolorsforindex() )
• Trying to set a valid background color using the transparent constant IMG_COLOR_TRANSPARENT

At the moment, I have it all for 1 test in my test case called testSetBackgroundColor() , however I feel that it should be 4 separate tests, since the test takes quite a long time and does a lot.

My question is: what should I do here? I encapsulate all this in 1 test of Image test case, or I divided it into separate tests, for example,

• testSetBackgroundColorErrors
• testSetBackgroundColorShorthandRGB
• testSetBackgroundColorRGB
• testSetBackgroundColorTransparent

I posed here a question about testing http://pastebin.com/f561fc1ab .

thanks

Answer 1

Separate it. That's right.

When the unit test fails, he should immediately understand what exactly is broken. If you combine tests, you will debug the unit test failure.

By the way, do you write tests first ? With TDD, this is unlikely to end in bloated trials.

Answer 2

My preference is to separate the tests as you describe.

• This makes it more obvious what went wrong when the test fails and therefore debugs faster
• You get the advantage of resetting objects to a clean initial state between test conditions
• This makes it easier to see the tests that you have included / omitted by simply looking at the method names.

Answer 3

I conceptually divided my testing into two categories (as many practicing TDD do): integration tests and unit tests. A unit test has to check one thing, and I have to be disciplined in testing the only contract that I write at any time - in general, one method requires one test. This makes me write small, tried and tested methods in which I am very confident. This, in turn, leads me to write small test classes.

Integration tests are higher-level tests that prove that interaction problems between components that are otherwise proven will work as expected in isolation through unit tests. I write less, and they need to be applied reasonably, since there can never be full coverage of the integration level. They seek to identify more risky areas of interaction between the various components and may use written acceptance tests as a guide.

Identifying areas that require integration testing is most likely a “feeling”. If you have been disciplined regarding unit tests, you should have a good idea where integration tests are needed, i.e. These are areas with deeper call stacks or interprocess communication or the like, where you know there is a higher risk. Or, you may decide that integration tests are a good way to prove high-level behavioral expectations that compare with the written requirements of the product owner. This is also helpful.

Answer 4

Yes, you should divide them into four tests. Perhaps you are reluctant because it duplicates the code. I read an article stating that unit tests should be very readable (sorry, I have no link). Further, ways to do this were discussed, but the point was to write utility functions.