The PHP podcast where everyone chimes in.

Originally aired on

November 3rd, 2016

055: Acceptance Testing with Behat

We chat about the open-source Behavior-Driven Development framework called Behat. We get a brief overview of how Behat can help us write more reliable code and also explore some best-practices when writing automated tests.


Acceptance Testing with Behat Show Summary

What does Behat do?

  • Behat is a BDD tool
  • Behat is even more BDD-specific than RSpec or phpspec
  • Behat separates semantics of problem description from automated tests
  • Behat can be seen more as a tool for documentation and specification than testing in the sense of removing bugs

How do we decide what to test with Behat?

  • The testing pyramid
  • We should have the lowest number of the tests which are the slowest to run
  • We can mock out external services in acceptance tests in the same way we use mocks and stubs in unit testing
  • If your test suite takes longer than 10 minutes, you have big problems
  • Favor lower-levels tests where possible

How can Behat help us to modernize legacy applications?

  • Write end-to-end tests with Behat to define expected behavior
  • Refactor underlying code into more defined 'layers' using acceptance tests to ensure we have not broken anything
  • As we refactor, replace slower acceptance tests with faster lower-level (unit/integration) tests
  • Only keep the most important acceptance tests

How do we isolate layers (esp. the UI layer) so we don't need end-to-end tests?

  • If our UI talks to the back end via REST, point it at a fake back-end
  • Use BDD or unit testing tools for javascript
  • Write feature files in a UI-agnostic way
  • If your tests are entangled, your application will be entangled
  • The same descriptions can be used with Behat and Cucumber JS. This allows your UI and back-end to be tested against the same specification

How do we write good user stories?

  • User stories should be the result of a conversation between developers and users
  • Keep the discussion high-level
  • Focus on understanding the problem, not the implementation details

How do we get started with Behat in a project that already has Unit Tests?

  • Behat expects to find a top-level dir called /features for specifications
  • /features does not contain tests - think of /features as documentation as well as specification
  • Within /tests, divide tests into /unit, /integration, /acceptance and namespace them
  • The content of /features should be human-readable, describe features to be used by humans and be implementation-agnostic

How do we acceptance test a user interaction with many variations?

  • We don't need to explicitly test every scenario end-to-end
  • Create scenario outlines with multiple examples
  • Identify the most critical paths and focus testing on those

Sammy Kaye wraps up with

Developer Shout-Out

Thank you, Wouter J for your contributions to Behat. A $50 Amazon gift card from Laracasts is on its way to you.

Shout-out sponsored by Laracasts


It's like Netflix for developers.


Jessica Mauerhan

Konstantin Kudryashov

Show Notes Credit

Chris Shaw

Thank you Chris Shaw for authoring the show notes for this episode!

If you'd like to contribute show notes and totally get credit for it, check out the show-notes repo!