PHPackages mgeoffray/magento-behat-extension - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. mgeoffray/magento-behat-extension ActiveLibrary mgeoffray/magento-behat-extension ================================= Magento Behat extension 1.0.2(8y ago)040MITPHPPHP ~5.3|~5.5|~7.0 Since Apr 9Pushed 8y ago1 watchersCompare [ Source](https://github.com/mgeoffray/BehatMage)[ Packagist](https://packagist.org/packages/mgeoffray/magento-behat-extension)[ Docs](https://github.com/MageTest/BehatMage)[ RSS](/packages/mgeoffray-magento-behat-extension/feed)WikiDiscussions master Synced 2mo ago READMEChangelog (3)DependenciesVersions (20)Used By (0) BehatMage --------- [](#behatmage) [![Build Status](https://camo.githubusercontent.com/725f5fe3db57a8bdfd622228bf31cd9ae39f3de622a1a0960eff1b74249a1e1b/68747470733a2f2f7472617669732d63692e6f72672f4d616765546573742f42656861744d6167652e706e673f6272616e63683d646576656c6f70)](https://travis-ci.org/MageTest/BehatMage)[![Scrutinizer Code Quality](https://camo.githubusercontent.com/f60ea0d82d8652c2b17aadab2725673ba5bc2648c2dd177724d5c6aea6b8feaa/68747470733a2f2f7363727574696e697a65722d63692e636f6d2f672f4d616765546573742f42656861744d6167652f6261646765732f7175616c6974792d73636f72652e706e673f623d646576656c6f70)](https://scrutinizer-ci.com/g/MageTest/BehatMage/?branch=develop) Behat extension for Magento, providing Behat context with specific Magento requirements allowing you to quickly define Magento scenarios and steps to enable BDD within Magento projects. Target ------ [](#target) - To create a tool that makes testing easy and straight forward to use for testing external behavior of Magento. - To create a tool that provides clear feedback when exceptions are raised. The feedback should coach the developer on how to resolve the issue and the messaging should be correct to the Magento domain. How? ---- [](#how) - The tool can be installed easily with composer. - The creation of standard scenarios can be accomplished without the need to create new contexts. - There are no exceptions raised that do not provide feedback on how to proceed or resolve the issue. - The documentation includes examples of how to use each feature of the tool. Installation ------------ [](#installation) ### Prerequisites [](#prerequisites) BehatMage requires PHP 5.3.x or greater. ### Install using composer [](#install-using-composer) For this document we assume the directory layout is as follows. ``` project-dir ├── behat.yml ├── bin │   └── behat ├── composer.json ├── composer.lock ├── features │   ├── bootstrap │   └── ... ├── htdocs │   ├── app │   ├── downloader │   ├── index.php │   ├── js │   ├── skin │   ├── var │   └── ... └── vendor ├── autoload.php ├── behat ├── magetest └── ... ``` We are assuming you will be keeping your behat features declarations and will be calling the behat script from your project directory (one step above your Magento base dir). Of course, any other layout is possible, too. Just be aware of the following adjustments you will have to make: - The behat.yml file needs to be in the directory where you call the behat script from. - The composer.json PSR-0 autoload path declaration will need to be adjusted. - The default.paths.features setting in your behat.yml will need to be adjusted. First, add BehatMage to the list of dependencies inside your `composer.json` and be sure to register few paths for autoloading: ``` { "config": { "bin-dir": "bin" }, "require": { "php": ">=5.3.0" }, "require-dev": { "magetest/magento-behat-extension": "feature/Behat3" }, "autoload": { "psr-0": { "": [ "htdocs/app", "htdocs/app/code/local", "htdocs/app/code/community", "htdocs/app/code/core", "htdocs/lib" ] } }, "minimum-stability": "dev" } ``` Then simply install it with composer: ``` $ composer install --dev --prefer-dist ``` You can read more about Composer on its [official webpage](http://getcomposer.org). Basic usage ----------- [](#basic-usage) Change directory to your project one and setup behat inside the directory: ``` $ cd project $ bin/behat --init ``` The behat --init will create a features/ directory with some basic things to get your started. The output on the screen should be similar to: ``` $ bin/behat --init +d features - place your *.feature files here +d features/bootstrap - place bootstrap scripts and static files here +f features/bootstrap/FeatureContext.php - place your feature related code here ``` ### Define your feature [](#define-your-feature) Everything in Behat always starts with a feature that you want to describe and then implement. In this example, the feature will be give an admin user the ability to manage review visibility, so we can start by creating a features/admin\_user\_manages\_review\_visibility.feature file: ``` Feature: Admin User can manage review visibility So that our Customers are not influenced by a product with bad review history, as an Admin User I want to disable reviews of those specific products ``` Every feature starts with this same format: a line naming the feature, followed by three lines that describe the benefit, the role and the feature itself. And while this section is required, its contents aren’t actually important to Behat or your eventual test. This section is important, however, so that each feature is described consistently and is readable by other people. ### Define a scenario [](#define-a-scenario) Next, add the following scenario to the end of the features/admin\_user\_manages\_review\_visibility.feature file: ``` Scenario: Turn off reviews per product Given the following products exist: | sku | name | accepts_reviews | | Ottoman1 | Ottoman | 1 | And "Ottoman1" has existing reviews When I turn reviews off for "Ottoman1" product Then no review should be displayed for "Ottoman1" ``` Each feature is defined by one or more “scenarios”, which explain how that feature should act under different conditions. This is the part that will be transformed into a test. Each scenario always follows the same basic format: ``` Scenario: Some description of the scenario Given [some context] When [some event] Then [outcome] ``` Each part of the scenario - the context, the event, and the outcome - can be extended by adding the And or But keyword: ``` Scenario: Some description of the scenario Given [some context] And [more context] When [some event] And [second event occurs] Then [outcome] And [another outcome] But [another outcome] ``` There’s no actual difference between, Then, And But or any of the other words that start each line. These keywords are all made available so that your scenarios are natural and readable. ### Executing Behat [](#executing-behat) You’ve now defined the feature and one scenario for that feature. You’re ready to see Behat in action! Try executing Behat from inside your project directory: ``` $ bin/behat ``` If everything worked correctly, you should see something like this: ``` Feature: Admin User can manage review visibility So that our Customers are not influenced by a product with bad review history, as an Admin User I want to disable reviews of those specific products Scenario: Turn off reviews per product # features/reviews/admin_user_manages_review_visibility.feature:7 Given the following products exist: | sku | name | accepts_reviews | | Ottoman1 | Ottoman | 1 | And "Ottoman1" has existing reviews When I turn reviews off for "Ottoman1" product Then no review should be displayed for "Ottoman1" 1 scenario (1 undefined) 4 steps (4 undefined) 0m1.836s You can implement step definitions for undefined steps with these snippets: /** * @Given /^the following products exist:$/ */ public function theFollowingProductsExist(TableNode $table) { throw new PendingException(); } /** * @Given /^"([^"]*)" has existing reviews$/ */ public function hasExistingReviews($arg1) { throw new PendingException(); } /** * @When /^I turn reviews off for "([^"]*)" product$/ */ public function iTurnReviewsOffForProduct($arg1) { throw new PendingException(); } /** * @Then /^no review should be displayed for "([^"]*)"$/ */ public function noReviewShouldBeDisplayedFor($arg1) { throw new PendingException(); } ``` ### Writing your step definition [](#writing-your-step-definition) Behat automatically finds the feature/admin\_user\_manages\_review\_visibility.feature file and tries to execute its Scenario as a test. However, we haven’t told Behat what to do with statements like Given the following products exist, which causes an error. Behat works by matching each statement of a Scenario to a list of regular expression “steps” that you define. In other words, it’s your job to tell Behat what to do when it sees Given the following products exist. Fortunately, Behat helps you out by printing the regular expression that you probably need in order to create that step definition: ``` You can implement step definitions for undefined steps with these snippets: /** * @Given /^the following products exist:$/ */ public function theFollowingProductsExist(TableNode $table) { throw new PendingException(); } /** * @Given /^"([^"]*)" has existing reviews$/ */ public function hasExistingReviews($arg1) { throw new PendingException(); } /** * @When /^I turn reviews off for "([^"]*)" product$/ */ public function iTurnReviewsOffForProduct($arg1) { throw new PendingException(); } /** * @Then /^no review should be displayed for "([^"]*)"$/ */ public function noReviewShouldBeDisplayedFor($arg1) { throw new PendingException(); } ``` Behat, however, is not aware yet of the Magento domain and it's requiring us to add step definitions that we likely want to skip because of their repetitive nature. We then have to make Behat be Magento aware using its configuration file behat.yml adding the following lines: ``` default: extensions: MageTest\MagentoExtension\Extension: base_url: "http://project.development.local" # The default is to have the features directory inside the project directory # If you want the features directory inside the Magento installation, set paths.features: #paths: # features: htdocs/features ``` where we tell Behat which extension to load and what store we want to test. Well done so far, we now have to tell Behat that we want to use, just for clarity, a specific sub context for every actor that we have, in our example admin user. In order to do so we have to update the features/bootstrap/FeatureContext.php file as following: ``` 0.1.0 BehatMage_Catalog Mage_Catalog_Model_Resource_Setup ``` ``` true local ``` ```