In memory state can get out of date between CLI and web requests,
leading to hard to debug errors. The performance impact of this
should be low, given the size of the JSON file.
This is a major refactoring of the testsession module to use a persistent file
storage instead of using $_SESSION storage. The primary reason for this is for
out-of-band tests (e.g. simplifying Behat tests, and testing modules like
silverstripe-resque (https://github.com/stojg/silverstripe-resque)). Testing
the silverstripe-resque module without this is impossible as the PHP code
running the job has been started and loaded into memory long before you started
a testsession.
By default, this will create a TESTS_RUNNING.json file in your webroot, which
means that tests need to be run as a user who has permission to create files
there. In practice, this means your webroot needs to be owned by your webserver
user. The reason we store the file here is that it will show up as a changed
file in version control, so it’s more prominent if developers can’t figure out
why there are issues with database content.
API CHANGES:
- Add persistent file storage (using webroot/TESTS_RUNNING.json) as a base.
- Update TestSessionController to use new TestSessionEnvironment class.
- Moved extension points from TestSessionController to TestSessionEnvironment.
- Moved loadFixtureIntoDb from TestSessionController to TestSessionEnvironment.
- Moved setState from TestSessionController to TestSessionEnvironment.
- Deprecated the use of TestSessionController::setState()
FIXES:
- Fixes TestSessionRequestFilter to use new TestSessionEnvironment instead of
$_SESSION.
MINOR:
- Renamed TestSesssionRequestFilter.php to fix spelling error (three ’S’s)
- Class did not need renaming, just the file itself.
We use testsession to build up test state e.g. for checking
logins, so having an admin logged-in to operate the testsession
controller is counterproductive.
- Allow limited state setting when session is already in progress
- Allow test sessions without a test database
- Denote an “in progress” session through a “testsession.started” session flag rather than the usage of a temporary database
Was relying on cookie to set on NEXT request, which was too late
since some of the following init logic relied on DB queries.
This happened to work if your non-test DB was already set up,
but failed on fresh checkouts.
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.
