In this post I’ll look at how to manage the use and maintenance of Phabric within a team of business analysts, testers and developers. Phabric is a dynamic fixture creation tool I created for use with the testing framework Behat. It allows you to embed fixture creation into your Gherkin feature files and scenarios. If you havent encountered the tool before please look at the Github page for more information.
In a recent conversation with Marcello Duarte we were discussing ways in which Behat and Phabric could be used by BA’s and testers to create scenarios that set up the state of a system and then test interactions based on that state.
Marcello’s main concern was that because Phabric works by mapping database tables to textual tables in Gherkin scenarios it will always be tightly linked to the underlying database implementation. This causes a number of problems:
1. BA’s and testers shouldn’t have to have an encyclopaedic knowledge of the database structure. In many companies the test teams are primarily ‘black box’ testing a system, they have no knowledge of the implementation within the system just its outputs given set inputs.
2. This approach doesn’t play well with an emergent design. Phabric assumes an existing database that is mapped via configuration files and is ready to be populated when a test is run. In an ideal world testers and BA’s should be able write a large body of tests for features before they are implemented by the development team.
Phabric has a number of features that can be used to mask the complexity of an underlying database implementation and keep the ‘Given’ steps of a scenario nice and simple. The following example illustrates this process.
In this example we will use a fictional company who organise events. The companies application has one database table ‘Event’. The event table has eight columns, they are named in an ugly way, some require specific data entry formats (eg MYSQL DateTime) and not all columns are necessary when creating a test event.
Event Table
event_id
event_name
event_start_date
event_end_date
event_in_progress
event_premium
event_location
event_capacity
The goal of this exercise is to make it easy for testers to write scenarios that involve populating this table. This can be done using the following Phabric features: changing the column names, using default values for non critical columns and data transforming functions to make input data look friendly.
The following example scenario shows these features in action:
Feature: Event page rendering test
Checks that the various features of the event page render correctly.
Scenario: Basic Event Is Displayed Correctly.
Given the following event exists
| Name | Start Date | End Date |
| BDD For Beginners | 12/12/12 | 13/12/12 |
When I got to the "home" page
Then I should see the "BDD For Beginners" event
We can see here that:
1. Names of columns are changed to something more readable than ‘event_start_time’
2. Not all columns are required. Under the hood default values are used when columns are not included in the Given step.
3. The values for start and end dates are not in the very verbose MySQL date format.
Note: Examples of how to acheive this with Phabric are available in the projects README and examples at GitHub
Developers can write the mappings for database tables, including sensible default values, column name transformations and column data transformations. It’s important that some kind of documentation exists for the test team. This could be an article on a project wiki or a text file in the projects repository. It should include:
1. Friendly names used to refer to data eg Name / event_name
2. Which data is required
3. What format should be used when entering data. eg – a bit column might be represented by the text ‘YES’ / ‘NO’.
4. A couple of examples of sample scenarios.
The additional work required by developers to create (and maintain) this documentation is quickly repaid by a more self sufficient test team capable of producing data driven scenarios independently of the development team. After the initial structure is in place testers can even add additional fields to Gherkin. The test will fail because the field wont map to the database implementation but the developer working on the feature can add to the existing implementation. They should then add this to the documentation.
Taking this idea one step further and looking at the issue of emergent design, is it possible for test teams to drive the development using Gherkin Tables to describe the desired entities in the system? Testers working closely with business analysts (or whomever it is that has the responsibility for creating stories) could define entities in the system up front.
One way of achieving this would be to write Gherkin tables representing the entities as part of the test creation process. When the tests are handed to developers they could then create a schema and Phabric mapping. They then continue to develop the feature as normal against the tests. Another way would be to produce a list of the required attributes of an entity up front and pass this to the development team ahead of test creation. They would then use this list to create schema and mapping files.
I hope this simple example has gone some way to illustrate how to use Behat and Phabric within an organisation to stream line the process of test creation. You may have noticed that the example conveniently glossed over relational data. Use of relational data requires some additional thought and development and will be the subject of my next blog post in this series.
Tags: BDD, behat, PHP, Testing
