PHPackages                             ssbehat/behat-quicksetup - 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. [Framework](/categories/framework)
4. /
5. ssbehat/behat-quicksetup

ActiveLibrary[Framework](/categories/framework)

ssbehat/behat-quicksetup
========================

Set up SilverStripe framework extension for Behat quickly

1.1.0(10y ago)21.5k1MITPHPPHP &gt;=5.3.2

Since Jul 18Pushed 10y ago1 watchersCompare

[ Source](https://github.com/jeffreyguo/SS-Behat-quicksetup)[ Packagist](https://packagist.org/packages/ssbehat/behat-quicksetup)[ Docs](http://silverstripe.org)[ RSS](/packages/ssbehat-behat-quicksetup/feed)WikiDiscussions master Synced 3w ago

READMEChangelog (1)Dependencies (16)Versions (5)Used By (0)

SilverStripe Integration for Behat
==================================

[](#silverstripe-integration-for-behat)

[![Build Status](https://camo.githubusercontent.com/fc4a296d5d5f8ef800c750f892d03a051ac8530be6f1d702ca3e029cb8fcf65e/68747470733a2f2f7472617669732d63692e6f72672f73696c7665727374726970652d6c6162732f73696c7665727374726970652d62656861742d657874656e73696f6e2e7376673f6272616e63683d6d6173746572)](https://travis-ci.org/silverstripe-labs/silverstripe-behat-extension)

Overview
--------

[](#overview)

[Behat](http://behat.org) is a testing framework for behaviour-driven development. Because it primarily interacts with your website through a browser, you don't need any specific integration tools to get it going with a basic SilverStripe website, simply follow the [standard Behat usage instructions](http://docs.behat.org/).

This extension comes in handy if you want to go beyond interacting with an existing website and database, for example make changes to your database content which would need to be rolled back to a "clean slate" later on.

It provides the following helpers:

- Provide access to SilverStripe classes in your Behat contexts
- Set up a temporary database automatically
- Reset the database content on every scenario
- Prebuilt Contexts for SilverStripe's login forms and other common tasks
- Creating of member fixtures with predefined permissions
- YML fixture definitions inside your Behat scenarios
- Waiting for jQuery Ajax responses (rather than fixed wait timers)
- Captures JavaScript errors and logs them through Selenium
- Saves screenshots to filesystem whenever an assertion error is detected

In order to achieve this, the extension makes one basic assumption: Your Behat tests are run from the same application as the tested SilverStripe codebase, on a locally hosted website from the same codebase. This is important because we need access to the underlying SilverStripe PHP classes. You can of course use a remote browser to do the actual testing.

Note: The extension has only been tested with the `selenium2` Mink driver.

Installation
------------

[](#installation)

Simply [install SilverStripe through Composer](http://doc.silverstripe.org/framework/en/installation/composer). Skip this step if adding the module to an existing project.

```
composer create-project silverstripe/installer my-test-project 3.1.x-dev

```

Switch to the newly created webroot, and add the SilverStripe Behat extension.

```
cd my-test-project
composer require "ssbehat/behat-quicksetup:*"

```

Run the following Shell script to help you setup Behat test session environment.

```
sh vendor/ssbehat/behat-quicksetup/appendixes/SS-behat-quick-setup.sh

```

Now get the latest Selenium2 server (requires Java):

```
wget http://selenium-release.storage.googleapis.com/2.44/selenium-server-standalone-2.44.0.jar

```

On OSX, you can also use [Homebrew](http://brew.sh/): `brew install selenium-server-standalone`. If you are having issues running Selenium with your browser please check that you're on the [latest driver](https://code.google.com/p/selenium/downloads/list), since the download link above might be out of date.

Ensure you have a supported version of firefox installed:

```
wget https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/26.0/mac/en-GB/Firefox%2026.0.dmg

```

Now install the SilverStripe project as usual by opening it in a browser and following the instructions. Protip: You can skip this step by using `[SS_DATABASE_CHOOSE_NAME]` in a global [`_ss_environment.php`](http://doc.silverstripe.org/framework/en/topics/environment-management)file one level above the webroot.

Unless you have [`$_FILE_TO_URL_MAPPING`](http://doc.silverstripe.org/framework/en/topics/commandline#configuration)set up, you also need to specify the URL for your webroot. Either add it to the existing `behat.yml` configuration file in your project root, or set is as an environment variable in your terminal session:

```
export BEHAT_PARAMS="extensions[SilverStripe\BehatExtension\MinkExtension][base_url]=http://localhost/"

```

Usage
-----

[](#usage)

### Starting the Selenium Server

[](#starting-the-selenium-server)

You can run the server locally in a separate Terminal session:

```
java -jar selenium-server-standalone-2.41.0.jar

```

In some cases it may be necessary to start a specific version of firefox

```
java -jar selenium-server-standalone-2.41.0.jar -Dwebdriver.firefox.bin="/Applications/Firefox26.app/Contents/MacOS/firefox-bin"

```

### Running the Tests

[](#running-the-tests)

Now you can run the tests (for example for the `framework` module):

```
vendor/bin/behat @framework

```

In order to run specific tests only, use their feature file name:

```
vendor/bin/behat @framework/login.feature

```

This will start a Firefox browser by default. Other browsers and profiles can be configured in `behat.yml`.

For example, if you want to start a Chrome Browser you can following the instructions provided [here](docs/chrome-behat.md).

Tutorials
---------

[](#tutorials)

- [Tutorial: Testing Form Submissions](docs/tutorial.md)
- [Tutorial: Webservice Mocking with Phockito and TestSession](docs/webservice-mocking.md)

Configuration
-------------

[](#configuration)

The SilverStripe installer already comes with a YML configuration which is ready to run tests on a locally hosted Selenium server, located in the project root as `behat.yml`.

You'll need to customize at least the `base_url` setting to match the URL where the tested SilverStripe instance is hosted locally. This

Generic Mink configuration settings are placed in `SilverStripe\BehatExtension\MinkExtension`, which is a subclass of `Behat\MinkExtension\Extension`.

Overview of settings (all in the `extensions.SilverStripe\BehatExtension\Extension` path):

- `framework_path`: Path to the SilverStripe Framework folder. It supports both absolute and relative (to `behat.yml` file) paths.
- `extensions.Behat\MinkExtension\Extension.base_url`: You will probably need to change the base URL that is used during the test process. It is used every time you use relative URLs in your feature descriptions. It will also be used by [file to URL mapping](http://doc.silverstripe.org/framework/en/topics/commandline#configuration) in `SilverStripeExtension`.
- `extensions.Behat\MinkExtension\Extension.files_path`: Change to support file uploads in your tests. Currently only absolute paths are supported.
- `ajax_steps`: Because SilverStripe uses AJAX requests quite extensively, we had to invent a way to deal with them more efficiently and less verbose than just Optional `ajax_steps` is used to match steps defined there so they can be "caught" by [special AJAX handlers](http://blog.scur.pl/2012/06/ajax-callback-support-behat-mink/) that tweak the delays. You can either use a pipe delimited string or a list of substrings that match step definition.
- `ajax_timeout`: Milliseconds after which an Ajax request is regarded as timed out, and the script continues with its assertions to avoid a deadlock (Default: 5000).
- `screenshot_path`: Absolute path used to store screenshot of a last known state of a failed step. Screenshot names within that directory consist of feature file filename and line number that failed.

Example: behat.yml

```
default:
  context:
    class: SilverStripe\MyModule\Test\Behaviour\FeatureContext
  extensions:
    SilverStripe\BehatExtension\Extension:
      screenshot_path: %behat.paths.base%/artifacts/screenshots
    SilverStripe\BehatExtension\MinkExtension:
      # Adjust this to your local environment
      base_url:  http://localhost/
      default_session: selenium2
      javascript_session: selenium2
      selenium2:
        browser: firefox

```

Module Initialization
---------------------

[](#module-initialization)

You're all set to start writing features now! Simply create `*.feature` files anywhere in your codebase, and run them as shown above. We recommend the folder structure of `tests/behat/features`, since its consistent with the common location of SilverStripe's PHPUnit tests.

Behat tests rely on a `FeatureContext` class which contains step definitions, and can be composed of other subcontexts, e.g. for SilverStripe-specific CMS steps (details on [behat.org](http://docs.behat.org/quick_intro.html#the-context-class-featurecontext)). Since step definitions are quite domain specific, its likely that you'll need your own context. The SilverStripe Behat extension provides an initializer script which generates a template in the recommended folder structure:

```
vendor/bin/behat --init @mymodule

```

You'll now have a class located in `mymodule/tests/behat/features/bootstrap/Context/FeatureContext.php`, as well as a folder for your features with `mymodule/tests/behat/features`. The class is namespaced, and defaults to the module name. You can customize this:

```
vendor/bin/behat --namespace='MyVendor\MyModule' --init @mymodule

```

In this case, you'll need to pass in the namespace when running the features as well (at least until SilverStripe modules allow declaring a namespace).

```
vendor/bin/behat --namespace='MyVendor\MyModule' @mymodule

```

Available Step Definitions
--------------------------

[](#available-step-definitions)

The extension comes with several `BehatContext` subclasses come with some extra step defintions. Some of them are just helpful in general website testing, other's are specific to SilverStripe. To find out all available steps (and the files they are defined in), run the following:

```
vendor/bin/behat @mymodule --definitions=i

```

Note: There are more specific step definitions in the SilverStripe `framework` module for interacting with the CMS interfaces (see `framework/tests/behat/features/bootstrap`). In addition to the dynamic list, a cheatsheet of available steps can be found at the end of this guide.

Fixtures
--------

[](#fixtures)

Since each test run creates a new database, you can't rely on existing state unless you explicitly define it.

### Database Defaults

[](#database-defaults)

The easiest way to get default data is through `DataObject->requireDefaultRecords()`. Many modules already have this method defined, e.g. the `blog` module automatically creates a default `BlogHolder` entry in the page tree. Sometimes these defaults can be counterproductive though, so you need to "opt-in" to them, via the `@database-defaults`tag placed at the top of your feature definition. The defaults are reset after each scenario automatically.

### Inline Definition

[](#inline-definition)

If you need more flexibility and transparency about which records are being created, use the inline definition syntax. The following example shows some syntax variations:

```
Feature: Do something with pages
	As an site owner
	I want to manage pages

	Background:
		# Creates a new page without data. Can be accessed later under this identifier
		Given a "page" "Page 1"
		# Uses a custom RegistrationPage type
		And an "error page" "Register"
		# Creates a page with inline properties
		And a "page" "Page 2" with "URLSegment"="page-1" and "Content"="my page 1"
		# Field names can be tabular, and based on DataObject::$field_labels
		And the "page" "Page 3" has the following data
		 | Content |  |
		 | My Property | foo |
		 | My Boolean | bar |
		# Pages are published by default, can be explicitly unpublished
		And the "page" "Page 1" is not published
		# Create a hierarchy, and reference a record created earlier
		And the "page" "Page 1.1" is a child of a "page" "Page 1"
		# Specific page type step
		And a "page" "My Redirect" which redirects to a "page" "Page 1"
		And a "member" "Website User" with "FavouritePage"="=>Page.Page 1"

	@javascript
	Scenario: View a page in the tree
		Given I am logged in with "ADMIN" permissions
		And I go to "/admin/pages"
		Then I should see "Page 1" in CMS Tree

```

- Fixtures are created where you defined them. If you want the fixtures to be created before every scenario, define them in [Background](http://docs.behat.org/guides/1.gherkin.html#backgrounds). If you want them to be created only when a particular scenario runs, define them there.
- Fixtures are cleared between scenarios.
- The basic syntax works for all `DataObject` subclasses, but some specific notations like "is not published" requires extensions like `Hierarchy` to be applied to the class
- Record types, identifiers, property names and property values need to be quoted
- Record types (class names) can use more natural notation ("registration page" instead of "Registration Page")
- Record types support the `$singular_name` notation which is also used to reference the types throughout the CMS. Record property names support the `$field_labels` notation in the same fashion.
- Property values may also use a `=>` symbol to indicate relationships between records. The notation is `=>.`. For `has_many` or `many_many` relationships, multiple relationships can be separated by a comma.

Writing Behat Tests
-------------------

[](#writing-behat-tests)

### Directory Structure

[](#directory-structure)

As a convention, SilverStripe Behat tests live in a `tests/behat` subfolder of your module. You can create it with the following command:

```
mkdir -p mymodule/tests/behat/features/bootstrap/MyModule/Test/Behaviour

```

### FeatureContext

[](#featurecontext)

The generic [Behat usage instructions](http://docs.behat.org/) apply here as well. The only major difference is the base class from which to extend your own `FeatureContext`: It should be `SilverStripeContext`rather than `BehatContext`.

Example: mymodule/tests/behat/features/bootstrap/MyModule/Test/Behaviour/FeatureContext.php

```
