Was missed from the removal of PHPUnitWrapper:
a16588aac3
Original reason for this: Don't fail dev/build without phpunit
When you install a SilverStripe project with "composer install --no-dev",
the PHPUnit dependency gets skipped. Which means the PHPUnit_Framework_TestListener
interface doesn't exist. The SilverStripe Classloader might still include
SapphireTestReporter which relies on this interface, which then breaks execution.
SS3 fixed this by NOT defining the class in the first place.
This has been removed in 2fdc96a0de (diff-82b3f89e8e5ae090c93e9c3a2ba8aa36L3),
as part of a PHPUnit version upgrade - but without an apparent fix to replace this.
API Remove Director::$test_servers / $dev_servers
API Remove MODULES_PATH / MODULES_DIR constants
ENHANCEMENT Injector backtick syntax now supports environment variables as well as constants
Fixes#6588
API Add HasRequestHandler interface
API Refactor Link() and url handling behaviour from Controller into RequestHandler
API RequestHandler classes now must define url_segment to have a default Link()
API Clean up redirectBack()
API Substitute Zend_Locale with Locale / NumberFormatter
API Substitute Zend_Date with IntlDateFormatter
API Added DBTIme::Nice12, FormatFromSettings
API Added Short() method to DBDate / DBTime / DBDatetime
API Add Date::getTimestamp()
API Added setSubmittedValue api for FormField
API Add second arg to base FormField::setValue()
API Major refactor of i18n into component data parts
API Implement Resettable interface to reset objects between tests
ENHANCEMENT Changed DBField::create_field return type to `static` to support better type hinting
ENHANCEMENT i18nTextCollector supports __CLASS__
API Implement enhanced pluralisation
Remove Zend_Translate and all Zend dependencies from i18n
Deprecated $context from i18n::_t()
Warn on missing default string for i18n::_t()
Created a generic DataObject FormFactory interface that can be substituted in place of getCMSFields. Different FormFactories can depend on different kinds of context, such as
'Record' or 'Controller' - it's the responsibility of the code calling the factory to interpret and
supply this context.
The expected use-case is that rather than overriding getCMSFields(), developers can
change CMS UIs by manipulating the FormFactory associated with the given DataObject.
This is an experimental UI and may change before 4.0 stable is released.