Top Ten Behat Tip

Using Behat for BDD with Symfony is always a good idea. Here are my top ten hints for getting the most out of this useful tool;

  1. The feature files should be understandable by a non-techical audience – so don’t use IDs of form elements and such like. Mink can find input boxes by label, name or placeholder. Every input on the web page must have something that identifies its function to the user so use that. What is easier to understand; When I enter “Fred” for “Username” – or – When I enter “Fred” for “#uname”
  2. Use the Behatch library to get step definitions that might be useful (
  3. Tag the scenarios to group them into sensible sub-sets. Such as “@security”, “@routing”, “@profile” – then you can just run a subset of the tests if you need to
  4. Ensure the database is in a known state before the tests start to run. This is probably the most important tip – you and your tests need to know exactly what is in the database before the tests start. There is a useful Doctrine class called the Purger which can empty database tables between tests.
  5. The Behat tests should only test outcomes that a regular user could verify, so try to avoid testing to see if an entity is updated in the database for example. If a user updates an entity for example, there should be some way in the user interface for them to verify that the change has been made – not by poking around in theĀ  database.
  6. The cheat sheet is useful – if you’re old school, print it out and keep it next to you. Otherwise, open it in your second screen
  7. If you must insist on checking in the database for a property of an entity, bear in mind that Doctrine might have cached the entity. So, your Feature Context might have loaded the entity from the database and, in running the test, Symfony might have modified the entity and saved the change to the database. If the test then tries to verify that an attribute has changed, its default position is to check the cached version of the entity – which, of course, will be exactly the same as it was when it loaded before the test ran. You’ll have to refresh the entity before doing the assertion – this forces Doctrine to reload the entity and to ignore any cached version.
  8. Make sure each Scenario has a unique and descriptive description – so when it fails in Jenkins you know where to start looking
  9. Don’t assume that the features will be tested in a certain order – so if a test changes something in the database, another test further down the line might fail as it could be assuming that the database is in another state (see 4)
  10. Don’t waste time writing steps that already exist – don’t write steps like “I should see the text” – use “I should see” – a built-in step from Mink. do “behat -dl” to see all the steps that are already written and available to use.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.