In computer science, the bridge pattern is meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation and can use inheritance to separate responsibilities into different classes.
Symfony defines several bridges to abstract third-party libraries such as Doctrine, Monolog, Swiftmailer and Twig. In Symfony 2.7 we added a new bridge for PHPUnit. This first version of the bridge provides the following features:
- It disables PHP's garbage collector for tests to avoid segmentation faults;
- It auto registers the needed classes to load Doctrine annotations;
- It reports a summary of deprecation notices at the end of the test suite.
The last feature is very useful for Symfony developers that are preparing the transition to Symfony 3. First, install the new PHPUnit bridge in your application executing the following command:
1
$ composer require --dev "symfony/phpunit-bridge":2.7.x@beta
Then, execute the test suite and you'll see a report of the deprecated Symfony features that your application is still using:
By default, deprecation notices will make tests fail. This behavior can be
controlled with the SYMFONY_DEPRECATIONS_HELPER
environment variable (default
value = strict
). Change the value of that variable to weak
to make the
bridge ignore deprecation notices. This is useful for projects that must use
deprecated interfaces for backward compatibility reasons.
In addition, you can safely mark a test as legacy using any of the following methods:
- Make its class start with the
Legacy
prefix; - Make its method start with
testLegacy
; - Make its data provider start with
provideLegacy
orgetLegacy
; - Add the
@group
legacy annotation to its class or method.
Thanx! Very nice feature, it will help to the future upgrade a lot!
Thanks, very very nice :)
Just a typo It disables PHP's garbage collector for tests to avoid segfaults (defaults)
I am sorry, I wasn't aware that segfaults is the abbreviation of "Segmentation fault".
@Mohamed thanks to your comment I've realized that "segfaults" is not a very intuitive term. I've just updated the article to say "segmentation faults" instead of "segfaults".