Unit Testing

I don't have time to write tests because I am too busy

Types of software testing

  • Unit Testing (do the parts perform correctly alone?)
  • Integration Testing (do the parts perform correctly together?)
  • User Acceptance Testing (does the system meet the end user's expectations?)

Types of software testing

Unit Testing vs Integration Testing

  • Unit Testing tests one layer
  • Integration Testing tests across layers

Concept of Unit Testing

  • A unit test is code that tests as small as possible a piece of functionality (the unit)
  • One function may have multiple unit tests according to the usage and outputs of the function
  • tests ensure
    • the code meets expectations and specifications
    • the code continues to meet expectations over time: avoiding regression
  • tests are consider as code behavior documentation

Unit Test Best Practices

  • Consistent
  • Atomic
  • Single Responsibility
  • Self descriptive
  • No conditional logic or loops
  • No exception handling
  • Informative Assertion messages

Consistent

Multiple runs of the test should consistently return true or consistently return false, provided no changes

Atomic

Only two possible results : PASS or FAIL
No partially successful tests

No side effects between tests


Isolation of tests

  • Different execution order must yield same results
  • Test B should not depend on outcome of Test A (use mocks instead)

Single Responsibility

One test should be responsible for one scenario only
Test behavior, not methods

  • One method, multiple behaviors -> multiple tests
  • One behavior, multiple methods -> one test

Self-descriptive

Unit test must be easy to read and understand

  • variable, method and class names must be self descriptive
  • no conditional logic
  • no loops

Name tests to represent PASS conditions:

  • canMakeReservation
  • totalBillEqualsSumOfMenuItemPrices
<?php
namespace Riskio\SpecificationTest;

use Riskio\Specification\AndSpecification;
use Riskio\SpecificationTest\Fixtures\NotSatisfiedSpecification;
use Riskio\SpecificationTest\Fixtures\SatisfiedSpecification;

class AndSpecificationTest extends \PHPUnit_Framework_TestCase
{
    /**
     * @test
     */
    public function isSatisfiedBy_GivenBothSpecificationsSatisfied_ShouldReturnTrue()
    {
        $spec = new AndSpecification(
            new SatisfiedSpecification(),
            new SatisfiedSpecification()
        );

        $isSatisfied = $spec->isSatisfiedBy('foo');

        $this->assertThat($isSatisfied, $this->equalTo(true));
    }

    /**
     * @test
     */
    public function isSatisfiedBy_GivenOneSpecificationNotSatisfied_ShouldReturnFalse()
    {
        $spec = new AndSpecification(
            new SatisfiedSpecification(),
            new NotSatisfiedSpecification()
        );

        $isSatisfied = $spec->isSatisfiedBy('foo');

        $this->assertThat($isSatisfied, $this->equalTo(false));
    }

    /**
     * @test
     */
    public function isSatisfiedBy_GivenBothSpecificationsNotSatisfied_ShouldReturnFalse()
    {
        $spec = new AndSpecification(
            new NotSatisfiedSpecification(),
            new NotSatisfiedSpecification()
        );

        $isSatisfied = $spec->isSatisfiedBy('foo');

        $this->assertThat($isSatisfied, $this->equalTo(false));
    }
}

No conditional logic or loops

Test should have no uncertainty:

  • All inputs should be known
  • Method behavior should be predictable
  • Expected output should be strictly defined
  • Split in to two tests rather than using "if" or "switch"

Test should not contain "while", "for" or "foreach" loops

  • If test logic has to be repeated, it probably means the test is too complicated
  • Call method multiple times rather than looping inside of method

No exception handling

Indicate expected exception
Catch only the expected type of exception
Fail test if expected exception is not caught
Let other exceptions go uncaught

<?php
use PHPUnit\Framework\TestCase;

class MyTest extends TestCase
{
    /**
     * @expectedException MyException
     * @expectedExceptionCode 20
     */
    public function testExceptionHasErrorCode20()
    {
        throw new MyException('Foo', 20);
    }

    /**
     * @expectedException MyException
     * @expectedExceptionMessage Foo
     */
    public function testExceptionHasErrorMessageFoo()
    {
        throw new MyException('foo', 20);
    }

    public function testExceptionHasErrorMessageBar()
    {
        $this->expectException(MyException::class);
        throw new MyException('foo', 20);
    }
}

Informative Assertion messages

By reading the assertion message, one should know why the test failed and what to do
Include business logic information in the assertion message
Good assertion messages:

  • Improve code documentation
  • Inform developers about the problem if the test fails

Pattern Arrange/Act/Assert (aka AAA)

  • Arrange initialize objects and prepare data needed for the test
  • Act call the tested method with prepared data
  • Assert uses assertion to determine if test passes or not

PHPUnit

Assertions

Assertions are the "checks" that you may perform to determine if a test passes or fails.

  • assertEquals/assertSame
  • assertTrue/assertFalse
  • assertInstanceOf
  • assertCount
  • assertArrayHasKey
  • assertInternalType
  • assertEmpty
  • assertRegExp

Assertions

As possible, you use only one assertion per test

Assertions

Use the more relevant assertion in each case.

 

assertEquals(true, $val)

assertTrue($val)

Assertions

Use the more relevant assertion in each case.

 

assertEquals(null, $val)

assertNull($val)

Assertions

Use the more relevant assertion in each case.

 

assertEquals(true, array_key_exists($items, $key))

assertArrayHasKey($key, $items)

Mock/Stub

A mock allows a dependency to be imitated so the Unit test can be isolated

  • Stub concern system under test (SUT). The Stub can never fail the test. We check the status of our SUT at the end of the test and not how this state was obtained. (state-based test)
  • Mock concern test itself. We have expectations that are verified during the execution of the test. The mock decide that the test fails or succeeded. (Interactions Testing)

Mock/Stub

Code Coverage

you can't go into production with less than 87% coverage

Code Coverage

Metric uses to determine code covered by unit tests
Useful to find untested code
Do not guarantee test quality and use cases coverage

 

We can have 100% code coverage without any assertions

Code Coverage

Code Coverage

PHPSpec

Behavioral Driven Development Oriented
Describing the software behavior


TDD focus on testing your application, BDD is more about describing its behavior

PHPSpec

Using a BDD approach will force you to constantly consider the actual requirements and desired behavior of the software you're building.

No code coverage

BDD

  • Behat that describe the external behavior of your application, using the readable Gherkin language
  • PHPSpec that describe the internal behavior of your application

Copy of Object Oriented Programming

By Nicolas Eeckeloo

Made with Slides.com

Copy of Object Oriented Programming

  • 748

More from Nicolas Eeckeloo