Magento Fireside BDD tools part 2

Posted August 14, 2014

Todays fireside chat focused on Behat and PHPSpec with a little BDD process as well. We attempted a live demo and with only a couple of technical issues I think it went very well.

Below are the presentation notes myself and Allan worked on.

The GitHub repository for the presentation can be gound here and as I said in the presentation we can only improve these tools with the help of you.. So add more ideas here

What is BDD ?

Software development practice that emphasises development through an example-based conversations with users and stakeholders of the system. The following are some of the processes involved.

  • Impact Mapping
  • Example Workshops
  • Feature Mapping ( Inviqa process )
  • User stories
  • Automated user story execution Behat
  • Unit level design tools PHPSpec

Coined by Dan north it has been used and adapted to help focus the business on what parts of the application deliver “real” business value. Why do we need this ? Waterfall worked to delivery an application? Well applications are large and complicated and without working with a dedicated product owner in an iterative way its hard if not impossible to change based on business direction as well as understanding what parts of the system will offer real value. Most applications are developed to save money or make money!!

What is Behat

Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria.

Behat is a BDD php framework, that allows developer to test PHP applications using human-readable sentences to describe features and scenarios about how the application should behave in order to test its functionality.

What is BehatMage

BehatMage is an extension for proving Behat with context about Magento specific functionality, allowing developers to define scenarios and steps for testing Magento with BDD tools.

Reasons for using BehatMage over just Behat are that we have included some initial step definitions for working with Magento a little easier. E.g. I log in as… I see in configuration… As well as fixtures that allow us to put the system in a known state before we start testing. E.g. Given the following products exist: Extending the BehatContext also provides us access to the Mage namespace so we can define our own assertions based on Magento objects.

What is PHPSpec

PHPspec is a development tool derived from BDD technique called specs or SpecBDD; there is no real difference between SpecBDD and TDD other than the language that is used to describe the scenarios and features.

When using PHPSpec the focus is all about the “Behaviour” of the method as opposed to traditional TDD where the focus is all on “testing”. We write our specifications as if we were talking to a stake holder in the project: It should do something when I apply something else.

What is MageSpec

MageSpec is an extension to the SpecBDD tool PHPSpec, Its main purpose is to allow an easy integration into Magento when describing behaviour. It does this by exposing the Magento classes required and creates a level of knowledge about Models Blocks and controllers… MageSpec helps keep the focus on the red green refactor loop by:

  • Describe
  • Implement
  • Refactor

We achieve this by adding additional helpers to the PHPSpec CLI for describing key components within Magento ( Blocks, Models, Controllers ) this validates the modules vendor name and module name to ensure Magento compatibility.

A recently added feature is automatic code generation for modules including app/etc/modules/…. and the concept of Magento code pools. For a developer this allows us to describe in the CLI, implement in the IDE and assert via the CLI reducing the need for manual steps of boilerplate code and browser refreshes.

This again relates back to the core principle of BDD that is “Deliver true business value” we describe part of the scenario and know when we have completed that section of the “Behaviour” it can help reduce the desire to add additional features. E.g. “But I think the client will want this in X period….” Or It would be great if this method could do “XXYYZZ”

Where do they fit into the process

BDD tools help us deliver true business value by only developing real business features. Using BDD also helps us communicate better between all people involved within the project. By talking in an ‘ubiquitous language’ and defining real life examples deliverables are easier to understand and prioritise to the business.

What is chase. Feature gathering and example feature files.

Chase is an online card processing provider. Our clients would like to integrate this into their Magento web shop to allow customers to checkout in a more convenient way as well as delivering value back to the business by providing lower handling costs that other providers.

Implement feature that fails

Feature: Chase Payments
   In order to pay for my online purchase
              As a customer
   I need to be able to use Chase as a payment method

Scenario: Customers can use chase as a payment method
    Given the following products exist:
        | sku  	| name 		|
        | 123 	| sample product 	|
     When I add “sample product” to the basket
     And I proceed to the payment step of the checkout
     Then I should be able to enter my bank details

Scenario: Chase can be configured by the site admin
    Given the “chase” module is installed on the store
    When I visit try and configure the module
    Then I should see an option to “enable/disable” the module

As we can see a story is comprised of the following elements:

  • Title: A clear description of the feature we are implementing.
  • Narrative: The narrative is comprised of three parts:
  • Role: The owner or main beneficiary of the feature.
  • Feature: The actual feature is been implemented.
  • Benefit: What is been gain by implementing the feature.
  • Scenarios: Stories are defined by one or more scenarios, scenarios explain how a feature should behave under different sets of conditions.

At the same time Scenarios are defined by three main parts:

  • Context: The context for this specific scenario, for example Given the customer is logged in.
  • Event: What the feature should be doing, for example When the customer clicks add to cart.
  • Outcome: The expect result from a given context and event, for example Then the product should be added to the shopping cart.

What makes a good user story ?

  • Clear connection to the business goal
  • Clear deliverable value to beneficiar
  • Easily understood by all parties
  • Always benefits a party.

We write our feature files using gherkin syntax where the Given is setting the state of the scenario, When is describing the behaviour and Then is asserting the outcome.

As always if you have any questions please let either myself or Allan know via twitter.

You may also find these related posts interesting: Developer Book Club All hail Xdebug and lets let var dump die A new look and a cleanup of content plus good bye github pages. Docker and Docker Sync