UNIT &
INTEGRATION
TESTING
David Berliner

Why Test
Types of Tests
PHPUnit
Writing Tests
Getting Stuck In

WHY TEST?

TESTS REDUCE BUGS

TESTS REDUCE BUGS
TESTS ARE GOOD DOCUMENTATION

TESTS REDUCE BUGS
TESTS ARE GOOD DOCUMENTATION
TESTS ALLOW SAFE REFACTORING

TESTS REDUCE BUGS
TESTS ARE GOOD DOCUMENTATION
TESTS ALLOW SAFE REFACTORING
TESTS REDUCE THE COST OF CHANGE

TESTS REDUCE BUGS
TESTS ARE GOOD DOCUMENTATION
TESTS ALLOW SAFE REFACTORING
TESTS REDUCE THE COST OF CHANGE
TESTING FORCES YOU TO THINK

TESTS REDUCE BUGS
TESTS ARE GOOD DOCUMENTATION
TESTS ALLOW SAFE REFACTORING
TESTS REDUCE THE COST OF CHANGE
TESTING FORCES YOU TO THINK
TESTS REDUCE FEAR

A study conducted by Microsoft and
IBM showed that writing tests can
add 15% – 35% to development time
but reduce the number of bugs by
40% – 90%.
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

TYPES OF TESTS

Black Box
White Box
Unit
Integration
Functional
System
Regression
Performance
Smoke
Canary
Usability
A/B
…

Black Box
White Box
Unit
Integration
Functional
System
Regression
Performance
Smoke
Canary
Usability
A/B
…

UNIT TESTS
The goal of unit testing is:
1. to isolate each part of the program, and

UNIT TESTS
The goal of unit testing is:
1. to isolate each part of the program, and
2. show that the individual parts are correct.

UNIT TESTS
The goal of unit testing is:
1. to isolate each part of the program, and
2. show that the individual parts are correct.
Unit tests have a very narrow and well-defined scope.

UNIT TESTS
Pro’s:
1. Fast

UNIT TESTS
Pro’s:
1. Fast
2. Simple to understand

UNIT TESTS
Pro’s:
1. Fast
2. Simple to understand
3. Reliable

UNIT TESTS
Pro’s:
1. Fast
2. Simple to understand
3. Reliable
Con’s:
1. Large time investment

UNIT TESTS
Pro’s:
1. Fast
2. Simple to understand
3. Reliable
Con’s:
1. Large time investment
2. Requires maintenance

UNIT TESTS
A unit test should NOT:
1. Access the network

UNIT TESTS
A unit test should NOT:
1. Access the network
2. Hit a database

UNIT TESTS
A unit test should NOT:
1. Access the network
2. Hit a database
3. Use the file system

UNIT TESTS
A unit test should NOT:
1. Access the network
2. Hit a database
3. Use the file system
4. Call other non-trivial components

INTEGRATION TESTS
Test the inter-operation of multiple subsystems.
Pro’s:
1. Make sure nuts and bolts
fit together

INTEGRATION TESTS
Test the inter-operation of multiple subsystems.
Pro’s:
1. Make sure nuts and bolts
fit together
2. Test behaviour
and infrastructure

INTEGRATION TESTS
Test the inter-operation of multiple subsystems.
Pro’s:
1. Make sure nuts and bolts
fit together
2. Test behaviour
and infrastructure
3. (tested code) / test % is high

INTEGRATION TESTS
Test the inter-operation of multiple subsystems.
Pro’s:
1. Make sure nuts and bolts
fit together
2. Test behaviour
and infrastructure
3. (tested code) / test % is high
Con’s:
1. Hard to test all critical paths

INTEGRATION TESTS
Test the inter-operation of multiple subsystems.
Pro’s:
1. Make sure nuts and bolts
fit together
2. Test behaviour
and infrastructure
3. (tested code) / test % is high
Con’s:
1. Hard to test all critical paths
2. Harder to localise source
of errors

TEST HIERARCHY

PHPUnit

1. Unit Testing Framework written in PHP by Sebastian Bergmann
2. De facto standard
3. Major Frameworks use it (Zend, Cake, Laravel, Symphony etc.)

Installation:
https://phpunit.de/manual/current/en/installation.html
Be sure to install xDebug in order to generate code coverage.
Note: PECL no longer supported

WRITING TESTS

ORGANISING TESTS
- The tests for class Foo are placed in a class FooTest
- Most of the time you will inherit from
PHPUnit_Framework_TestCase
PHPUnit_Extensions_Database_TestCase
- Tests are public methods named test*
- Inside the test methods, assertion methods such as
assertEquals() are used.

ORGANISING TESTS
Tests should mirror the code being tested.
SRC
SomeFolder
Baz.php
Foo.php
Bar.php
TEST
SomeFolder
FooTest.php
BarTest.php
BazTest.php

PHPUNIT.XML

BOOTSTRAP.PHP

ASSERTIONS
assertArrayHasKey()
assertClassHasAttribute()
assertClassHasStaticAttribute()
assertContains()
assertContainsOnly()
assertContainsOnlyInstancesOf()
assertCount()
assertEmpty()
assertEqualXMLStructure()
assertEquals()
assertFalse()
assertFileEquals()
assertFileExists()
assertGreaterThan()
assertGreaterThanOrEqual()
assertInstanceOf()
assertInternalType()
assertJsonFileEqualsJsonFile()
assertJsonStringEqualsJsonFile()
assertJsonStringEqualsJsonString()
assertLessThan()
assertLessThanOrEqual()
assertNull ( )
assertObjectHasAttribute()
assertRegExp()
assertStringMatchesFormat()
assertStringMatchesFormatFile()
assertSame()
assertStringEndsWi th()
assertStringEqualsFile()
assertStringStartsWi th()
assertThat()
assertTrue()
assertXmlFileEqualsXmlFile()
assertXmlStringEqualsXmlFile()
assertXmlStringEqualsXmlString()

ASSERTIONS

ANNOTATIONS @DEPENDS

ANNOTATIONS @DATAPROVIDER

ANNOTATIONS @EXCEPTIONS

What do you do if the code you want to test
is dependent on other components that
cannot be used in the test environment?

MOCKS & STUBS

DATABASE TESTING
Four stages of a DB test
1. Set up fixture
2. Exercise System Under Test
3. Verify outcome
4. Teardown

DATABASE TESTING (CONT) Give it a connection

DATABASE TESTING (CONT) Flat XML DataSet

DATABASE TESTING (CONT)

DATABASE TESTING (CONT)

GETTING STUCK IN

Demo:
https://github.com/manatok/talk-demo-ci

• db - Database Skel file and patches
• src - Project Code
• test/Output - Code coverage
• test/SportsBet - Projects Tests
• test/TestingCore - Uti l i ties
• tools - CI tools including ANT build
file