tonyair/silverstripe-testsession
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-testsession synced 2024-10-22 14:06:00 +02:00
Code Issues Projects Releases Wiki Activity
9 Commits 13 Branches 22 Tags 480 KiB
PHP 94.3%
Scheme 4.8%
JavaScript 0.7%
CSS 0.2%
78062a093c
Go to file
Sam Minnee 78062a093c NEW: Add status code comment to testsession/start output. 
testsession/start now includes a comment of the form <!-- SUCCESS: DBNAME=DatabaseName -->,
which can be used by behat and other consumers to validate that the tesession was actually
started.

It's included the database name in its output, which is a small piece of information
disclosure, but not a big deal compared to the generally dev-only nature of this module.

It requires a fix to Cookie::set(), to ensure that set cookies also apperar immediately
in $_COOKIE.  Otherwise the call to DB::get_alternative_database_name() after it is set
won't return a value.
2013-06-19 12:20:12 +02:00
_config Initial commit 2012-12-19 14:20:06 +01:00
code NEW: Add status code comment to testsession/start output. 2013-06-19 12:20:12 +02:00
templates NEW: Add status code comment to testsession/start output. 2013-06-19 12:20:12 +02:00
_config.php Check for Security.token before setting test session state 2013-06-04 15:00:54 +02:00
composer.json Limiting version dependency to 3.0 2013-04-09 09:53:01 +02:00
README.md NEW Mailer class and mock date support 2012-12-19 15:47:39 +01:00

README.md

Browser Test Session Module

Overview

This module starts a testing session in a browser, in order to test a SilverStripe application in a clean state. Usually the session is started on a fresh database with only default records loaded. Further data can be loaded from YAML fixtures.

The module also serves as an initializer for the SilverStripe Behat Extension. It is required for Behat because the Behat CLI test runner needs to persist test configuration just for the tested browser connection, available on arbitary URL endpoints. For example, we're setting up a test mailer which writes every email into a temporary database table for inspection by the CLI-based process.

Setup

In order to execute the commands, the environment must be in "dev mode", or you must be logged-in with administrative permissions.

Since the database name is stored as an encrypted cookie, you need to create a secure token for the encryption first:

sake dev/generatesecuretoken

The resulting configuration code needs to be placed in mysite/_config.php.

Usage

You start a test session by manually requesting a certain URL, and interact with it through other URL endpoints.

Commands:

  • dev/testsession/start: Sets up test state, most commonly a test database will be constructed, and your browser session will be amended to use this database. See "Parameters" documentation below.
  • dev/testsession/end: Removes the test state, and resets to the original database.
  • dev/testsession/loadfixture?fixture=<path>: Loads a fixture into an existing test state.
  • dev/testsession/clear: Empties the test state.

Parameters for "dev/testsession/start":

  • fixture: Loads a YAML fixture in the format generally accepted by SapphireTest (see fixture format docs). The path should be relative to the webroot.
  • database: Set an alternative database name in the current browser session as a cookie. Does not actually create the database, that's usually handled by SapphireTest::create_temp_db(). Note: The database names are limited to a specific naming convention as a security measure: The "ss_tmpdb" prefix and a random sequence of seven digits. This avoids the user gaining access to other production databases available on the same connection.
  • mailer: Subclass of Mailer, typically used to record emails instead of actually sending them.
  • date: Sets a simulated date used for all framework operations. Format as "yyyy-MM-dd HH:mm:ss" (Example: "2012-12-31 18:40:59").

Example usage with parameters:

dev/testsession/start?database=ss_tmpdb_1234567&fixture=cms/tests/controller/CMSMainTest.yml