Unit testing with PHPUnit - there's life outside of TDD

UNIT TESTING
WITH PHPUNIT
Paweł Michalik

THERE'S LIFE OUTSIDE OF TDD
Hofmeister, ideals are a beautiful thing, but
over the hills is too far away.
Loose translation from "The loony tales" by Kabaret Potem

WHAT?
Tests that check if a certain unit of code (whatever it means)
works properly
Tests for given unit are independent from the rest of the
codebase and other tests

FOR WHAT?
Easy regression finding
Can make you more inclined to use certain good practices
(dependency injection FTW)
Helps catching dead code
Documentation without documenting

WITH WHAT?
PhpUnit!
There should be an installation manual
But let's be serious - nobody will remember that

A UNIT OF CODE
class LoremIpsum
{
private $dependency;
public function getDependency()
{
return $this->dependency;
}
public function setDependency(Dependency $dependency)
{
$this->dependency = $dependency;
}
}

A UNIT OF CODE CONTINUED
class LoremIpsum
{
public function doStuff()
{
if (!$this->dependency) {
throw new Exception("I really need this, mate");
}
$result = array();
foreach ($this->dependency->getResults() as $value) {
$value = 42 / $value;
$value .= ' suffix';
$result[$value] = true;
}
return $result;
}
}

WE CAN'T TEST THESE
class LoremIpsum
{
private $dependency;
}

WE DON'T WANT TO TEST THOSE
class LoremIpsum
{
public function getDependency()
{
return $this->dependency;
}
public function setDependency(Dependency $dependency)
{
$this->dependency = $dependency;
}
}

WHAT DO WE NEED TO TEST HERE?
{
}
$result = array();
}
return $result;
}

WHY NOT THIS?
{
}
$result = array();
}
return $result;
}

THIS TOO, BUT...
1. Unit testing doesn't replace debugging.
2. Unit testing can make your code better, but won't really do
anything for you.
3. Unit testing focus your attention on what the code does, so
you can spot potential problems easier.

LET'S CHECK IF IT WORKS
class LoremIpsumTest extends PHPUnit_Framework_TestCase
{
public function testDoingStuffTheRightWay()
{
$testedObject = new LoremIpsum();
$testedObject->setDependency(new Dependency());
$this->assertInternalType('array', $testedObject->doStuff());
}
}

LET'S CHECK IF IT DOESN'T WORK
{
/**
* @expectedException Exception
* @expectedExceptionMessage I really need this, mate
*/
public function testDoingStuffTheWrongWay()
{
$testedObject->doStuff();
}
}

ASSERTIONS
Assertions have to check if the expected value corresponds
to an actuall result from the class we test.
Fufilling all of the assertions in a test means a positive result,
failing to meet any of them means a negative result.

CHOICE APLENTY
assertContains
assertCount
assertEmpty
assertEquals
assertFalse
assertFileExists
assertInstanceOf
assertSame
assertNull
...

EXCEPTIONS:
When we want to check if a method throws an exception,
instead of using assertX, we use annotations that will provide
the same service.
/**
* @expectedException ClassName
* @expectedExceptionCode 1000000000
* @expectedExceptionMessage Exception message (no quotes!)
* @expectedExceptionMessageRegExp /^Message as regex$/
*/

EXCEPTIONS:
Or methods, named in the same way as annotations:
$this->expectException('ClassName');
$this->expectExceptionCode(1000000000);
$this->expectExceptionMessage('Exception message');
$this->expectExceptionMessageRegExp('/^Message as regex$/');

TO SUMMARIZE:
1. Testing for edge cases (check for conditional expression
evaluating to both true and false)
2. Testing for match of actuall and expected result
3. And thrown exceptions
4. We can think of unit test as a way of contract
5. We don't test obvious things (PHP isn't that
untrustworthy)

WHERE DO WE GET DEPENDENCY FROM??
{
{
}
}

WHAT DOES THE DEPENDENCY DO?
{
{
}
}

UNIT TEST FOR A GIVEN CODE UNIT ARE INDEPENDENT FROM
OTHER CODE UNITS

UNIT TEST FOR A GIVEN CLASS ARE INDEPENDENT FROM ITS
DEPENDENCIES

We can test the dependency and make sure it returns some
kind of data, but what if we pass a different object of the same
type instead?

In that case we need to check what happend if the
dependency returns:
Values of different types
Values in different formats
Empty value
How many additional classes do we need?

TEST DOUBLES
Objects imitating objects of a given type
Used only to perform tests
We declare what we expect of them
We declare what they can expect of us
And see what happens

TERMINOLOGY
Dummy - object with methods returning null values
Stub - object with methods returning given values
Mock - as above and also having some assumptions in
regard of executing the method (arguments passed, how
many times it's executed)
And a lot more

YOU DON'T HAVE TO REMEMBER THAT THOUGH
Terms from the previous slide are often confused, unclear or
just not used.
You should use whatever terms are clear for you and your
team or just deal with whatever is thrown at you.
Often the test double framework will determine it for us.

PHPUnit comes with a mocking framework, but lets you use
any other you want.

LET'S MAKE A DEPENDENCY!
{
/**
* @var PHPUnit_Framework_MockObject_MockObject|Dependency
*/
private $dependencyMock;
public function setUp()
{
$this->dependencyMock = $this->getMockBuilder(Dependency::class)
->disableOriginalConstructor()
->setMethods(array('getResults'))
->getMock();
}
}

WILL IT WORK?
{
public function testDoingStuffTheRighterWay()
{
$testedObject->setDependency($this->dependencyMock);
$this->assertEmpty($testedObject->doStuff());
}
}

LETS DESCRIBE OUR REQUIREMENTS
{
public function testDoingStuffTheRighterWay()
{
$this->dependencyMock->expects($this->once())
->method('getResults')
->willReturn(array());
$this->assertEmpty($testedObject->doStuff());
}
}

WHAT IS PROVIDED IN MOCKBUILDER?
Defining mocked methods
If we won't use setMethods - all methods will return null
If we pass an array to setMethods:
Methods which names we passed can be overwritten
or will return null
Methods which names we didn't pass will behave as
specified in the mocked class
If we passed null to setMethods - all methods will behave
as specified in the mocked class

WHAT ELSE IS PROVIDED IN MOCKBUILDER?
Disabling the constructor
Passing arguments to the constructor (if it's public)
Mocking abstract classes (if we overwrite all abstract
methods)
Mocking traits

GREAT EXPECTATIONS
expects() method lets us define how many times (if ever) a
method should be executed in given conditions.
What can we pass to it?
$this->any()
$this->once()
$this->exactly(...)
$this->never()
$this->atLeast(...)
...

WHAT WE CAN OFFER?
with() methods allows us to inform the mock what
parameters are expected to be passed to method.
What can we pass to it?
Concrete value (or many if we have many arguments)
$this->isInstanceOf(...)
$this->callback(...)

IF A METHOD DOES NOT MEET THE EXPECTATIONS OR DOESN'T
GET REQUIRED PARAMETERS THE TEST WILL FAIL!

WHAT DO WE EXPECT IN RETURN?
willX() methods allow us to define what should be returned
from a method in given circumstances.
While previous methods were more like assertions, willX()
allows us to define methods behaviour.
That allows us to test different cases without creating any
additional classes.

WHAT CAN WE USE?
willReturn()
willReturnSelf()
willReturnCallback()
...

SUMMARY:
1. With mock objects we cas pass dependencies of a given
type without creating an actual object (isolation1)
2. We can test different cases without creating any new
classes or parametrisation
3. They free us from the necessity of creating dependencies
of dependencies
4. Make test independent from external resources as
webservices or database
5. Create additional test rules

AFTER CHANGES
public function divideAndSuffixDependencyResults()
{
throw new Exception("You need to specify the dependency");
}
$result = array();
$sanitizedValue = (float)$value;
if ($sanitizedValue == 0) {
continue;
}
$sanitizedValue = 42 / $sanitizedValue;
$sanitizedValue .= ' suffix';
$result[] = $sanitizedValue;
}
return $result;
}

ANSWER
public function testDivideByZeroIgnored() {
->willReturn(array(0));
$result = $testedObject->divideAndSuffixDependencyResults();
$this->assertEmpty($result);
$this->assertInternalType('array', $result);
}

ANOTHER ANSWER
public function testDivideByZeroIgnored2() {
->willReturn(array(0,2));
$this->assertEquals($result, array('21 suffix'));
}

YET ANOTHER ANSWER
public function testDivideByZeroIgnored3() {
->willReturn(array(0,2));
$this->assertCount(1, $result);
}

PROPER ANSWER DOESN'T MATTER IF WE ASK FOR SOMETHING
ELSE THAN WE ACTUALLY HAVE TO KNOW

ORGANISING TEST
Libraries should have test directory on the same level as
directory with sources
Applications should have test directory on the same level
as directory with modules
Bootstrap.php (autoloader) and PHPUnit configuration
should be inside the test directory
Directory hierarchy inside the test directory should be the
same as in the sources directory
If we use different types of tests - the test directory should
be also divided into subdirectories (unit, integration,
functional)

<phpunit bootstrap="Bootstrap.php" colors="true">
<testsuites>
<testsuite name="Application">
<directory>./ApplicationTests</directory>
</testsuite>
</testsuites>
</phpunit>

ONE CLASS - AT LEAST ONE TEST SUITE
Two simple rules:
1. If a few tests need a different setup than others - we should
move the setup operations into those tests (or extract a
method that creates that setup)
2. If many tests need a different setup than others - we should
move those test to a different suite and have a separate
setup

WHY SETUP() WHEN YOU CAN __CONSTRUCT()?
setUp() is executed before every test, providing a "fresh"
testing environment every time.
Its counterpart is takeDown(), executed after every test.

TESTS AS DOCUMENTATION
Lets call our tests a little different:
public function testDivisionAndSuffixReturnsArray
WhenDependencyIsProvided();
public function testDivisionAndSuffixThrowsException
WhenDependencyWasNotProvided();
public function testDivisionAndSuffixIgnoresResultsEquivalentToZero();
public function testDivisionAndSuffixIgnoresResultsEquivalentToZero2();
public function testDivisionAndSuffixIgnoresResultsEquivalentToZero3();

Lets make our configuration a little different:

<phpunit bootstrap="Bootstrap.php" colors="true">
<testsuites>
<testsuite name="Application">
<directory>./ApplicationTests</directory>
</testsuite>
</testsuites>
<logging>
<log type="testdox-text" target="php://stdout">
</log></logging>
</phpunit>

Run it and...

APPLICATIONTESTSSERVICELOREMIPSUMDIV
ISIONANDSUFFIX
Returns array when dependency is provided
Throws exception when dependency was not provided
Results equivalent to zero are not processed

All we have to do is to change testdox-text to testdox-html
and provide a file path!
Or use --testdox-html parameter in terminal.

JUST ADVANTAGES!
1. Two tasks done at once
2. Clear naming convention...
3. ...which also helps to decide what to test
4. Plus a convention of separating test into suites

CODE COVERAGE
1. Easy way to see what was already tested and what we still
have to test
2. Can help with discovering dead code
3. Is not a measure of test quality

CODE COVERAGE
1. Easy way to see what was already tested and what we still
have to test
2. Can help with discovering dead code
3. IS NOT A MEASURE OF TEST QUALITY

HOW DID DEPENDENCY GOT INTO THIS?

ANYTHING ELSE?
C.R.A.P. (Change Risk Analysis and Predictions) index -
relation of cyclomatic complexity of a method to its code
coverage.
Low complexity means low risk, even without testing
(getters, setters)
Medium complexity risks can be countered with high code
coverage
High complexity means that even testing won't help us

HOW TO TEST WHAT WE CAN'T REACH?
abstract class AbstractIpsum
{
protected $dependency;
public function __construct($parameter)
{
if (is_object($parameter)) {
$this->dependency = $parameter;
} else if (is_string($parameter)) {
if (class_exists($parameter)) {
$this->dependency = new $parameter;
} else {
throw new Exception($parameter." does not exist");
}
} else {
throw new Exception("Invalid argument");
}
}
}

NOT THIS WAY FOR SURE
public function testPassingObjectAsParameterAssignsObjectToProperty()
{
$expectedValue = new DateTime();
$mock = $this->getMockBuilder(AbstractIpsum::class)
->setConstructorArgs(array($expectedValue))
->getMockForAbstractClass();
$this->assertSame($expectedValue, $mock->dependency);
}

REFLECTION TO THE RESCUE!
public function testPassingObjectAsParameterAssignsObjectToProperty()
{
$reflectedClass = new ReflectionClass(AbstractIpsum::class);
$property = $reflectedClass->getProperty('dependency');
$property->setAccessible(true);
$actualValue = $property->getValue($mock);
$this->assertSame($expectedValue, $actualValue);
}

We'll go through only one test, but it's easy to spot that this
class have bigger potential. If we wrote more tests we could
use a different approach.
Instead of creating mock in every test we could create in
during setup, don't call the constructor and use reflection to
call it in our tests.

IN ACTION
public function testPassingObjectAsParameterAssignsObjectToProperty2()
{
$mockClosure = Closure::bind(
function (AbstractIpsum $abstractIpsum) {
return $abstractIpsum->dependency;
},
null,
AbstractIpsum::class
);
$actualValue = $mockClosure($mock);
$this->assertSame($expectedValue, $actualValue);
}

CAN WE TEST PRIVATE METHODS THIS WAY?

NO
It is possible in practice, but worthless. We test only the
public methods and their calls should cover private methods.
Private methods are what's called 'implementation detail' and
as such should not be tested.

OK, BUT I HAVE LOTS OF LOGIC IN A PRIVATE METHOD AND I
WON'T TEST IT THROUGH API
This is a hint that there's a bigger problem behind. You should
think if you actually shouldn't:
1. Change it to public
2. Extract it to its own class (method object pattern)
3. Extract it, along with similar methods, to their own class
(maybe we failed with the whole single responsibility
principle thing)
4. Bite the bullet and test through the API

SUMMARY
1. Tests organisation - directories and files resemble the
project hierarchy
2. We don't need to test a whole class in one test suite
3. We can make documentation writing tests
4. If we need to access private fields and methods we can use
reflection and Closure API

PHPUNIT PLUGINS
https://phpunit.de/plugins.html

PHPUNIT PLUGINS
https://github.com/whatthejeff/nyancat-phpunit-
resultprinter

PROPHECY
https://github.com/phpspec/prophecy

MUTATION TESTING
Testing tests
Unit tests are executed on slightly changed classes
Changes are made to logic conditions, arithmetic
operations, literals, returned values, and so on
Shows us if code regressions were found by our tests
https://github.com/padraic/humbug

RECOMMENDED READING
xUnit Patterns
PHPUnit manual
Michelangelo van Dam - Your code are my tests!
Marco Pivetta - Accessing private PHP class members
without reflection

THANKS FOR WATCHING!
http://pawelmichalik.net/presentations

Unit testing with PHPUnit - there's life outside of TDD

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Unit testing with PHPUnit - there's life outside of TDD

Similar to Unit testing with PHPUnit - there's life outside of TDD (20)

Recently uploaded

Recently uploaded (20)

Unit testing with PHPUnit - there's life outside of TDD