highly extensible, highly enjoyable, BDD testing framework for PHP.

Testing Languages

By default, Peridot uses a BDD style DSL for describing your code's behavior via specs. Here's the breakdown:

• describe($description, $func)

  This function creates a suite, and is used to organize behaviors. It's fair game to nest these.

• context($description, $func)

  This function is identical to describe. It is provided to offer additional organization for your specs.

• beforeEach($setupFunc)

  You can add setup functions that execute for all specs using this function. If you set variables on $this inside of the function body, it will create instance variables that are inherited by specs and suites.

• afterEach($tearDownFunc)

  You can add teardown functions that execute for all specs using this function.

• it($description, $func)

  This function creates a single test and adds it to the suite it is nested in.

An example might look like this:

<?php
describe('TodoRepository', function () {
    beforeEach(function () {
        $interface = 'Doctrine\Common\Persistence\ObjectManager';
        // lets assume we are using the peridot-prophecy-plugin
        $this->em = $this->getProphet()->prophesize($interface);
        $this->repository = new TodoRepository($this->em->reveal());
    });

    afterEach(function () {
        $this->getProphet()->checkPredictions();
    });

    context('when calling ->get()', function () {
        it('should find the todo', function () {
            $this->repository->get(1);
            $this->em->find('Todos\Todo', 1)->shouldBeCalled();
        });
    });
});

Pending Specs

"Pending" specs are not executed, but still appear in Peridot's output. This is typically used to temporarily skip a broken spec or suite.

You can make any spec or suite pending, by prefixing the function with an x.

<?php
xdescribe('A pending suite', function() {
    xcontext('when using a pending context', function() {
        xit('should have a pending spec', function() {
            // ...
        });
    });
});

Or you can simply omit the test function.

<?php
describe('A pending suite', function() {
    it('should have a pending spec');
});

Focused Specs

"Focusing" lets you isolate indivdual specs or suites. If there are focused specs in a suite, then any unfocused specs in the same suite will be skipped entirely.

You can make any spec or suite "focused", by prefixing the function with an f.

<?php
describe('A suite with nested suites', function() {
    fcontext('A focused suite', function() {
        it('should execute this spec', function() {
            // ...
        });

        it('should also execute this spec', function() {
            // ...
        });
    });

    describe('An unfocused suite', function() {
        it('should not execute this spec', function() {
            // ...
        });
    });
});

A suite is also considered "focused" if any of its nested specs or suites are focused. This allows focusing of a deeply nested spec without the pain of also marking all of its ancestors as focused.

<?php
describe('A suite with nested suites', function() {
    context('A suite with nested focused specs', function() {
        fit('should execute this spec', function() {
            // ...
        });

        it('should not execute this spec', function() {
            // ...
        });
    });

    describe('An unfocused suite', function() {
        it('should not execute this spec', function() {
            // ...
        });
    });
});

If multiple specs or suites within a suite are focused, then all the focused specs will be executed:

<?php
describe('A suite with nested suites', function() {
    fit('should execute this spec', function() {
        // ...
    });

    fit('should also execute this spec', function() {
        // ...
    });

    it('should not execute this spec', function() {
        // ...
    });
});

When any combination of fdescribe(), fcontext(), or fit() is used, Peridot will exit with a status code of 2 (unless a focused spec actually failed, in which case the status code will be 1). This helps prevent accidentally committed focused tests from passing under CI conditions.

If you wish to use focused tests with a CI service, it is recommended to use the --focus and/or --skip command line options instead, as these will not affect Peridot's exit status code.

Custom DSLs

You can also create your own testing DSLs! Check out Example: Creating An Acceptance Testing DSL.

The linked example above demonstrates creating a custom DSL to support the following testing language:

<?php
Feature("chdir","
    As a PHP user
    I need to be able to change the current working directory",
    function () {

        Scenario(function () {

            Given('I am in this directory', function () {
                chdir(__DIR__);
            });

            When('I run getcwd()', function () {
                $this->cwd = getcwd();
            });

            Then('I should get this directory', function () {
                if ($this->cwd != __DIR__) {
                    throw new \Exception("Should be current directory");
                }
            });

        });

    });

Assertions

A Peridot test fails when an exception is thrown. Peridot's default DSL configures the default behavior of PHP's native assert function to throw exceptions, but you could just as easily use an existing matcher library or roll your own.

We recommend the Leo assertion and matcher library. It was developed by the Peridot team to create an expressive assertion language to complement Peridot's BDD style. However, Peridot was built to be unopinionated about such things, and you can find a list of other matchers here.