Flushing should be off by default, just like it is when you are on the site normally.
It's not obvious that tests always flush when they run and you have to pass flush=0 to turn them off. People expect to have to flush to clear the cache, and the documentation already covers mentions about flushing
-> http://doc.silverstripe.org/en/developer_guides/testing/unit_testing/
-> phpunit framework/tests '' flush=all
# Run tests with optional `$_GET` parameters (you need an empty second argument)
Detect and parse HTTP_AUTHORIZATION for basic authentication running PHP in CGI mode
Add comments about using CGI mode with Apache and Basic Auth in /docs/en/topics/environment-management.md
Added notes to docs/en/changelogs/3.1.9.md
When using data providers with tests, the reporter appears to get confused and run callbacks in a weird order. This checks that the current suite before adding more details.
I've decoupled `Cookie` from the actual act of setting and getting
cookies. Currently there are a few limitations to how Cookie works that
this change mitigates:
0. `Cookie` currently changes the super global `$_COOKIE` when setting
to make the state of an application a bit more managable, but this is
bad because we shouldn't be modifying super globals
0. One can't actually change the `$cookie_class` once the
`Cookie::$inst` has been instantiated
0. One can't test cookies as there is no class that holds the state of
the cookies (it's just held in the super global which is reset as part
of `Director::test()`
0. One can't tell the origin of a cookie (eg: did the application set it
and it needs to be sent, or did we receive it from the browser?)
0. `time()` was used, so testing was made difficult
0. There was no way to get all the cookies at once (without accessing
the super global)
Todos are on the phpdoc and I'd like to write some tests for the backend
as well as update the docs (if there are any) around cookies.
DOCS Adding `Cookie` docs
Explains basic usage of `Cookie` as well as how the `Cookie_Backend`
controls the setting and getting of cookies and manages state of sent vs
received cookies
Fixing `Cookie` usage
`Cookie` is being used inconsistently with the API throughout framework.
Either by not using `force_expiry` to expire cookies or setting them to
null and then expiring them (which is redundant).
NEW `Director::test()` takes `Cookie_Backend` rather than `array` for `$cookies` param
In cases where CLI tidy fails to recognise HTML with errors or
unknown HTML5 elements, it doesn't output any content and
CSSContentParser fails.
This adds the --force-output parameter so that it always outputs
the input content, even if it wasn't completely fixed by tidy.
It seems that tidy class in PHP already does this, so this just
fixes the CLI use of tidy in CSSContentParser to be consistent.
This fix can be observed on the HHVM travis builds, as tidy isn't
compiled into HHVM as an extension.
Example: you have a site in a sub-directory off the webroot, you call
->Link() on a SiteTree record, which returns "/[sitedir]/my-page", and
you pass this URL to Director::test(). It's a valid URL, but
Director::test() will throw a 404.
Director::test() should be ensuring that all URLs passed to it are
properly made relative, not just in the case where it thinks the URL
is absolute.
Summary:
PHPUnit 3.8+ adds a method to its PHPUnit_Framework_TestListener called addRiskyTest(). Need to stub it out to avoid "must implement this interface method" fatals when using 3.8+
Test Plan:
Reviewers:
CC:
Task ID: #
Blame Rev:
Provides an interface for classes to implement their own flush()
functionality. This function gets called early in a request on
all implementations of Flushable when flush=1|all is requested in the
URL.
This fix came out of an issue where Requirements combined files were not
being cleaned up after dev/build?flush=1, due to the fact that flush
would only occur when you called it while on a page that used those
combined files, but not in any other contexts. This will now call flush
on any implementors of Flushable regardless of the context of where
flush was called.
BUG Fix incompatibility in Member_GroupList
Fix regressions in merges from 3.1
BUG Fix Security failing on test classes
BUG Fix postgresql compatibility
Clarify sql encoding of table names
Database abstraction broken up into controller, connector, query builder, and schema manager, each independently configurable via YAML / Injector
Creation of new DBQueryGenerator for database specific generation of SQL
Support for parameterised queries, move of code base to use these over escaped conditions
Refactor of SQLQuery into separate query classes for each of INSERT UPDATE DELETE and SELECT
Support for PDO
Installation process upgraded to use new ORM
SS_DatabaseException created to handle database errors, maintaining details of raw sql and parameter details for user code designed interested in that data.
Renamed DB static methods to conform correctly to naming conventions (e.g. DB::getConn -> DB::get_conn)
3.2 upgrade docs
Performance Optimisation and simplification of code to use more concise API
API Ability for database adapters to register extensions to ConfigureFromEnv.php
FIX for phpunit error message: ERROR [Strict Notice]: Declaration of SapphireTest::assertNotContains() should be compatible with PHPUnit_Framework_Assert::assertNotContains, and the same error for assertContains()
Move functionality from static start and destroy functions into instance
methods, allowing these to be overloaded. This works the same way as
calling Session::set() which then in turn calls inst_set()
Additionally use Injector to create the default Session instance to
allow the class to be swapped out.
The current docs for `objFromFixture` cause PHPStorm to generate an error because of the mismatched data types.
`$product = $this->objFromFixture('ProductPage', 'StandardSpecs');`
Causes: `Expected The, got string`.
Summary:
PHPUnit 3.8+ adds a method to its PHPUnit_Framework_TestListener called addRiskyTest(). Need to stub it out to avoid "must implement this interface method" fatals when using 3.8+
Test Plan:
Reviewers:
CC:
Task ID: #
Blame Rev:
Defaulting to MySQL here is really dumb. There is an explicit type as an argument so falling back to mysql could result in "I couldn't write to path ....db" despite the real error that the include of the sqlite3/code/SQLiteDatabaseConfigurationHelper.php failed for some reason.
Other uses of getDatabaseConfigurationHelper also need a similar error handler.
Avoid unparsed HTML responses in case of httpError(4xx) or
httpError(5xx) in live mode. The SS_HTTPResponse_Exception constructor
automatically set "text/plain" a content type, which conflicts
with the later choice of Debug::friendlyError() to return HTML.
This is a hotfix, needs more work to properly separate
logic flow from presentation concerns (e.g. through request processors).
