# Assumes path relative to vendor/silverstripe/silverstripe-behat
framework_path: ../../../framework/
ajax_steps:
- go to
- follow
- press
- click
- submit
Behat\MinkExtension\Extension:
# Adjust this to your local environment
base_url: http://localhost/
files_path: %behat.paths.features%/files/
default_session: selenium2
javascript_session: selenium2
goutte: ~
selenium2:
browser: firefox
Here's an overview of the non-stndard settings we've added.
You'll need to customize at least the `framework_path` and `base_url` setting.
*`default.context.parameters.screenshot_path`: Used to store screenshot of a last known state
of a failed step. It defaults to whatever is returned by PHP's `sys_get_temp_dir()`.
Screenshot names within that directory consist of feature file filename and line
number that failed.
*`default.extensions.SilverStripe\BehatExtension\Extension.framework_path`: Path to the SilverStripe Framework folder. It supports both absolute and relative (to `behat.yml` file) paths.
*`default.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`.
*`default.extensions.Behat\MinkExtension\Extension.files_path`: Change to support file uploads in your tests. Currently only absolute paths are supported.
*`default.extensions.SilverStripe\BehatExtension\Extension.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.
### Additional profiles
By default, `MinkExtension` is using `FirefoxDriver`.
Let's say you want to user `ChromeDriver` too.
You can either override the `selenium2` setting in default profile or add another
profile that can be run using `bin/behat --profile=PROFILE_NAME`, where `PROFILE_NAME`
could be `chrome`.
chrome:
extensions:
Behat\MinkExtension\Extension:
selenium2:
capabilities:
browserName: chrome
version: ANY
## Usage
### Starting the selenium server
You can either run the server in a separate Terminal tab:
Fixtures should be provided in YAML format (standard SilverStripe fixture format)
as [PyStrings](http://docs.behat.org/guides/1.gherkin.html#pystrings)
Take a look at the sample fixture logic first:
Given there are the following Permission records
"""
admin:
Code: ADMIN
"""
And there are the following Group records
"""
admingroup:
Title: Admin Group
Code: admin
Permissions: =>Permission.admin
"""
And there are the following Member records
"""
admin:
FirstName: Admin
Email: admin@test.com
Groups: =>Group.admingroup
"""
In this example, the fixture is used to create Admin member with admin permissions.
As you can see, there are special Gherkin steps that take care of loading
fixtures into database. They use the following format:
Given there are the following TableName records
"""
RowIdentifier:
ColumnName: Value
"""
Fixtures may also use a `=>` symbol to indicate relationships between records.
In the example above `=>Permission.admin` will be replaced with row `ID` of a
`Permission` record that has `RowIdentifier` set as `admin`.
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 usually not cleared between scenarios. You can alter this behaviour
by tagging the feature or scenario with `@database-defaults` tag.
The module runner empties the database before each scenario tagged with
`@database-defaults` and populates it with default records (usually a set of
default pages).
## FAQ
### Why does the module need to know about the framework path on the filesystem?
Sometimes SilverStripe needs to know the URL of your site. When you're visiting
your site in a web browser this is easy to work out, but if you're executing
scripts on the command-line, it has no way of knowing.
To work this out, this module is using [file to URL mapping](http://doc.silverstripe.org/framework/en/topics/commandline#configuration).
### How does the module interact with the SS database?
The module creates temporary database on init and is switching to the alternative
database session before every scenario by using `/dev/tests/setdb` TestRunner
endpoint.
It also populates this temporary database with the default records if necessary.
It is possible to include your own fixtures, it is explained further.