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).
Until now debug.log files were loaded into memory, concatenated and then re-written to disk. This is an intensive operation on a large file.
I've added the `FILE_APPEND` flag to append to this file instead.
If any of the functionality triggered by Director::isDev()
was causing deprecation errors, the system would go into
an infinite loop. Since the only way to cause this is the DB
checking functionality, we disable that for Deprecation.
Side effect of this change: You can't show deprecation notices
on a live site by forcing the session into dev mode.
When a unit test being run by PHPUnit encountered a fatal error,
TestRunner::tearDown was never being called. This resulted in tmpdb schemas
littering the database from failed test runs. This changeset fixes the issue
by registering TestRunner::tearDown as a shutdown function, so that it gets
called even in the event of a PHP Fatal Error.
There is no reason to try to run test cases of a class that is abstract. By
skipping them we allow developers to create abstract test case classes that
have test functions in them. This is especially helpful when someone is
testing multiple implementations of the same service interface. Most of their
tests can be in the abstract class, and then they can create concrete test
classes for each of their implementations and inherit all of the testing that
is built into the abstract class.
