phpconf.asia 2016 - bdd with behat for beginners

BDD w/Behat for

BeginnersAdam Englander

Session BreakdownPreface (this)Intro to BDDIntro to BehatBuild some Tests

Why Are You Here?What is your role in the development lifecycle?What is your reason for attending this session?What do you hope to get out of this session?What is your experience level with PHP, Behat, and BDD?

Pre-Run ChecklistMake sure you have:

PHP 5.6+ComposerA browser with the Selenium driverSelenium Server Standalone (Optional for 2.x)

GotchasMissing one of these extensions:

curlmbstringopenssl

No default timezone in PHP.ini

Building for BehaviorIntroduction to Behavioral

Driven Development

What is BDD?BDD is business driven, user focused, and test first. It focuses on delivering business value as effectively and efficiently as possible while maintaining consistent quality throughout the entire application.BDD is a methodology built around the principles of lean development, extreme programming, test driven development, and domain driven design.

What BDD ProvidesBetter understanding of the business requirement for development and QABetter understanding of existing features for the businessBetter communication via a ubiquitous languageReal insight into the business effect of a defect

What BDD Doesn’t ProvideThe answer to all your problemsA replacement for unit testingA replacement for manual testingSuper easy to implement everywhere right this secondA measure of code quality

Failed to Assert False is Trueor

How I learned to love BDD

How to write effective featuresStory BDD

Stay FocusedIt is crucial to the success of BDD to focus on what value a feature provides to the business.Always understand the the role of the user and their relationship to the feature. Do not get distracted by the technical aspects of the implementation.

Story BDD HierarchyFeature

BackgroundScenario

Step StepScenario

Step Step

Writing FeaturesApplications are comprised of featuresBDD discretely separates each featureEach feature contains a narrative and a scenarioFeature may also contain a background to set the stage for the feature scenarios

NarrativeFeature narratives are written similarly to Agile/Scrum stories and must answer these questions:

What is the business benefit?Who is the beneficiary?What is the action performed?

BackgroundA background should contain steps common to all, or at least most, scenarios to prepare the application environment for the scenarios.Background steps should be tested elsewhere as part of another feature.Steps failing in the background steps will identify that the failure is not related to the feature.

ScenarioA scenarios should contain a narrativeScenarios work in a manner similar to unit tests by arranging the environment necessary to begin the test, perform actions, and then assert that the expected results have been attainedScenarios should not test multiple features. Do not perform actions after assertions.

Scenario OutlineScenario outlines use a common set of steps with placeholders for data provided in a data table. They are a replacement for multiple scenarios in which data is the only differentiator and does not define the feature. Adding sales tax would be an example of a feature in which the data in the action and assertion would be different.

StepSteps do one of the following:

Arrange the environmentPerform an actionAssert a result of the previous actions

Steps should be reasonably reusableSteps should be aggregated for simplification when arranging the environment

French and FantasticIntroduction to Behat

What is Behat?Open source Behavior Driven Development framework for PHPOfficial PHP implementation of CucumberOne of the easiest Cucumber implementations to get up and running quicklyGood documentation: http://docs.behat.org

InstallationPHAR installation

Single global installOne version for feature contexts

Project InstallationComposer based install as dependencyVersion and dependencies tied to project

ComponentsCommand line executable – behatConfiguration file – behat.ymlFeature context(s)Feature Files

Command Line ExecutableAllows for initializing the environmentRunning features

Features and scenarios filterable by tagsChooses environment

Listing step definitions

Configuration FileSplit up into profiles (inherit from default)Configures custom autoloader pathDefines global tag filters

Defines output formattersDefines feature suitesConfigures extensions

Feature ContextDefines stepsMay extend other contextsMay access other contextsMay add hooks for pre/post tag, step, scenario, feature, and suite execution.

GherkinGherkin is a Domain Specific Language (DSL) utilized to write Features in Behat. It uses key words to identify the type of step:

Given – ArrangeWhen – ActThen - Assert

Example GherkinFeature: Home Page

Scenario: Login Link Given I am on the homepage When I click " Login" Then I will be on the "LaunchKey | Log in" page

Step Backing CodeMethod on a feature contextContains doc block annotated (@) matchers

Support defined in context. Defaults to TurnipSupports Turnip and regular expressions

Can contain examples doc blockCan contain descript in the doc block

Example Step/** * Opens homepage * Example: Given I am on "/" * Example: When I go to "/" * Example: And I go to "/” * @Given (I )am on :path * @When (I )go to :path */ public function visitPath($path) { $this->browser->open($path); }

Let’s see Behat at workDemo Time

Create a ProjectComposer “init”Add requirementsBehat “init”Add Contexts to Config

Verify Your InstallRun “vendor/bin/behat –h”You should see the help text

Initialize BehatInitialize the behat project via the Behat CLI with the --init flagVerify by running “vendor/bin/behat”

Add Mink to Config• Add the extension to the default profile• Set the base URL• Add the drivers

Add Contexts to Config• Add Mink context to get access to pre-

built browser steps• Add project context to make custom

steps

Verify ConfigurationRun “vendor/bin/behat –dl”You should see a LOT of stepsRun “vendor/bin/behat –di”You should see additional information for the steps

Lets Write A Feature TestUser Story:In order to use the siteAs a site visitorI can access the website

Let’s Make AnotherRequirement:In order to be a userAs a visitorI can register for a user account

What About Clean UpRequirement:E-Mail Address is the user identifier and must be unique among all users

We’re going to have to clean up users in a hook

Steps Need to Be IntuitiveChecking for errors on registration submission will require a custom step with some additional logic

Add Other Requirements

E-Mail Address is the user identifier and must be unique among all usersName is required and captures the users namePassword is required and must utilize a verification field to ensure correct password entry

Finish Up Labs/Examples

Server and Behat features found in GitHub: https://github.com/aenglander/bdd-with-behat-for-beginnersMaster branch is BehatMaster is tagged to go step by stepServer branch is server

SeleniumIndustry standardServer with remote APIDirect integration with Behat/Mink via Selenium DriverCan be used headless with PhantomJS via GhostDriver implementation

Using Selenium ServerAdd config to bahat.yml and specify browserApply @javascript tag to scenarios or a featureStart Selenium Standalone ServerRun tests

Selenium GridAllows for multiple simultaneous test runs, multiple browser versions, and multiple operating systemsOne Hub and Multiple NodesUses same app as Standalone ServerCan be flakey and hard to manage

Sauce Labs/BrowserStackSpecial Drivers for Sauce Labs and BrowserStackNot well documented but work very wellAllow for a “Grid” style environment without managing the Grid

Configuring Mink Driver

Poorly documentedEasy to figure out the settings by looking at the driver factories. See:

vendor/behat/mink-extension/src/Behat/MinkExtension/ServiceContainer/Driver

Best PracticesFeature files contain one FeatureFeatures should be more business than technical focused

Best Practices (cont.)Use the three A’s

Arrange – Background – GivenAct – WhenAssert - Then

Best Practices (cont.)Make steps visually verifiable. Feature files should be able to serve as documentationClean up after yourselfScenarios should be idempotentSpend the time to do it the right way