highly extensible, highly enjoyable, BDD testing framework for PHP.
By default, Peridot uses a BDD style DSL for describing your code's behavior via specs. Here's the breakdown:
This function creates a suite, and is used to organize behaviors. It's fair game to nest these.
This function is identical to
describe. It is provided to offer additional organization for your specs.
You can add setup functions that execute for all specs using this function. If you set variables on
$thisinside of the function body, it will create instance variables that are inherited by specs and suites.
You can add teardown functions that execute for all specs using this function.
This function creates a single test and adds it to the suite it is nested in.
An example might look like this:
"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.
Or you can simply omit the test function.
"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.
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.
If multiple specs or suites within a suite are focused, then all the focused specs will be executed:
When any combination of
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
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
--skip command line options instead, as these will not affect Peridot's exit status code.
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:
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.