Over a million developers have joined DZone.

Practical PHP Testing Patterns: State Verification

DZone's Guide to

Practical PHP Testing Patterns: State Verification

· Web Dev Zone
Free Resource

Try RAD Studio for FREE!  It’s the fastest way to develop cross-platform Native Apps with flexible Cloud services and broad IoT connectivity. Start Your Trial Today!

How do you test your code? USually the simplest way involves creating a System Under Test and its necessary fixtures, or collaborators. Then you can exercise it by calling one or more methods. After the act phase, you inspect the final state you have reached, checking that the expected results are there.

This state can also be the output of the system, as a SUT can actually be stateless (think of a mathematical library.)

Moreover, you can also select a subset of the state which is more deterministic or less fragile: you can test the number of elements in a collection instead of looking at all the fields of all its objects.

What I have just described is the most classic (overloaded term) way to test: assertion methods are in fact a mean to implement this pattern, which is named State Verification.


Some notes on this pattern: it requires methods, or other mechanisms to access the state to evaluate. It's not always possible if we want an effective encapsulation and to avoid a fragile test: for example accessing it is not recommended to access private fields via reflection, or even accessing them via getters created just for the purpose of testing.

There are some workarounds, not very satisfying, to add production code only to expose state: the state may be stored in another component injected in the SUT, or in something that the SUT accesses, like a database.

The problem of hidden state is crucial at the application level: when doing acceptance tests, it's difficult to avoid skipping the Facade exposed by the application and making assertion on the database. However, if your system (or class) does not have a way to manage its internal state, is more a smell of an incomplete Api than of meddling tests. For example Nat Pryce, author of Growing Object-Oriented Software, sees TDD at the system scale as a way to drive the development of tools for managing the system...


In State Verification tests, we only care about the final result, not about what the SUT goes through to produce it. A short definition of this mindset is testing what and not how.

If necessary, we can simplify and isolate the SUT by injecting or passing to it Stubs or Fakes (but not mocks).

These Test Doubles feed the SUT canned results. For example, you can substitute a collaborator which calculates square roots with a Test Double that implements the Identity function, in order to check only the current object and not also its collaborators.

However, isolation is not enforced: in the Fowler's version of State Verification, you have freedom to do functional (group of objects) tests instead of unit (single object with behavior plus optional test doubles) ones. Functional and end-to-end tests usually employ State Verification.


There are two stages of State Verification, ordered by complexity:
  • in Procedural State Verification, you run a battery of assertions on results a/o the SUT to verify that they are in the correct state;
  • in the Expected State Specification version, you build a specification for the require state, and then use a special Assertion Method to compare the state in the SUT to the expected one.
The second variation scales better, and results in readable tests. But when the state space is small or simple to grasp, the ROI of the approach is low.


The sample code is straightforward: using state verifications over scalars and objects, also with an example of Expected State Specification.

This example outlives this article: in the next episode, we will compare State Verification with Behavior Verification, and we'll see how these tests change if we change our approach.


class StateVerificationTest extends PHPUnit_Framework_TestCase
* Procedural State Verification on a result.
public function testConcatenesTwoStrings()
$joiner = new Joiner(':');
$result = $joiner->join(array('/home', '/'));
$this->assertEquals('/home:/', $result, 'The state of the result is not the expected one.');

* Procedural State Verification on the SUT.
public function testThatUsesStateVerificationOnTheSUTItself()
$car = new Car();
$this->assertEquals(20, $car->getSpeed());

* Expected State Verification on the result. For simplicity the SUT
* is a native function that calculates square roots.
public function testThatUsesExpectedStateSpecification()
$isBetween4and5 = $this->logicalAnd($this->greaterThan(4), $this->lessThan(5));
$result = sqrt(17);
$this->assertThat($result, $isBetween4and5);

class Joiner
private $separator;

public function __construct($separator)
$this->separator = $separator;

public function join(array $strings)
return implode($this->separator, $strings);

class Car
private $speed = 0;

public function accelerate()
$this->speed += 10;

public function getSpeed()
return $this->speed;


Martin Fowler wrote a discussion on State Verification versus mocking, but the discussion is out-of-date.

In the GOOS mailing list, the hypothesis that there are multiple, disjointed styles of TDD has been refuted. In fact, you should use both State Verification and Behavior Verification depending on the context and what is easier to simplify your design.

Get Your Apps to Customers 5X Faster with RAD Studio. Brought to you in partnership with Embarcadero.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}