turned deprecation notices as fatal when running unit tests #13644
Conversation
fabpot
commented
Feb 10, 2015
| Q | A |
|---|---|
| Bug fix? | no |
| New feature? | no |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | n/a |
| License | MIT |
| Doc PR | n/a |
| <!-- Disable E_USER_DEPRECATED until 3.0 --> | ||
| <!-- php -r 'echo -1 & ~E_USER_DEPRECATED;' --> | ||
| <ini name="error_reporting" value="-16385"/> | ||
| <ini name="error_reporting" value="-1" /> |
There was a problem hiding this comment.
I suggest removing this entirely from the phpunit config (as done before the change avoiding deprecation failures). What do you think ?
There was a problem hiding this comment.
I think it's great to set the expectation here, code should work fine with the highest level of error reporting (it was unsafe to rely on the PHP setting IMO).
There was a problem hiding this comment.
Explicit better than implicite here for me also
There was a problem hiding this comment.
Isn't that the default value that phpunit sets anyway?
There was a problem hiding this comment.
I think not: phpunit just keeps values from php.ini
There was a problem hiding this comment.
True, I just tested it. It uses whatever is configured in your own php.ini which by default probably does not enable all errors because PHPs default is not so strict. So I agree it should be set explicitly to -1.
|
I think this should be done in the 2.3 branch. For some reason the deprecations are also ignored in the components 2.3 branches even though there are no deprecations triggered at all. So Edit: PR for 2.3 #13652 |
|
I guess the reason is that tests in symfony components/bundles that require other symfony components will also trigger deprecation warnings when it uses the For example, the 2.3 branch of FrameworkBundle will still trigger deprecations when used with the 2.7 branch of Routing component. This is because https://github.com/symfony/symfony/pull/13361/files#diff-e0e88bc9bb34bea0301096304e2701b5 was only fixed in 2.7 but not in 2.3. To avoid this problem in the future, I think it makes more sense to add deprecation triggers IMMEDIATLY when it was actually marked as that. This will allow us to see code fragments in symfony we need to change to not trigger deprecation warnings immediatly. Our current process is really hard to maintain as we add triggers later and then only realize we need to fix other calling parts in older branches. |
|
One solution is to backport many fixes to older branches which is quite alot of work. |
|
see #13398 |
This PR was merged into the 2.7 branch. Discussion ---------- [PhpUnit] new PhpUnit bridge | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #13644 | License | MIT | Doc PR | - From the proposed README: PHPUnit Bridge ============== Provides utilities for PHPUnit, especially user deprecation notices management. It comes with the following features: * disable the garbage collector; * auto-register `class_exists` to load Doctrine annotations; * print a user deprecation notices summary at the end of the test suite. Handling user deprecation notices is sensitive to the SYMFONY_DEPRECATIONS_HELPER environment variable. This env var configures 3 behaviors depending on its value: * when set to `strict`, all but legacy-tagged deprecation notices will make tests fail. This is the recommended mode for best forward compatibility. * `weak` on the contrary will make tests ignore all deprecation notices. This is the recommended mode for legacy projects that must use deprecated interfaces for backward compatibility reasons. * any other value will respect the current error reporting level. All three modes will display a summary of deprecation notices at the end of the test suite, split in two groups: * **Legacy** deprecation notices denote tests that explicitly test some legacy interfaces. In all 3 modes, deprecation notices triggered in a legacy-tagged test do never make a test fail. There are four ways to mark a test as legacy: - make its class start with the `Legacy` prefix; - make its method start with `testLegacy`; - make its data provider start with `provideLegacy` or `getLegacy`; - add the `@group legacy` annotation to its class or method. * **Remaining/Other** deprecation notices are all other (non-legacy) notices, grouped by message, test class and method. Usage ----- Add this bridge to the `require-dev` section of your composer.json file (not in `require`) with e.g. `composer require --dev "symfony/phpunit-bridge"`. When running `phpunit`, you will see a summary of deprecation notices at the end of the test suite. Deprecation notices in the **Remaining/Other** section need some thought. You have to decide either to: * update your code to not use deprecated interfaces anymore, thus gaining better forward compatibility; * or move them to the **Legacy** section (by using one of the above way). After reviewing them, you should silence deprecations in the **Legacy** section if you think they are triggered by tests dedicated to testing deprecated interfaces. To do so, add the following line at the beginning of your legacy test case or in the `setUp()` method of your legacy test class: `$this->iniSet('error_reporting', -1 & ~E_USER_DEPRECATED);` Last but not least, you should then configure your C.I. to the reporting mode that is appropriated to your project by setting SYMFONY_DEPRECATIONS_HELPER to `strict`, `weak` or empty. It is recommended to start with `weak` mode, upgrade your code as described above, then when the *Remaining/Other* sections are empty, move to `strict` to keep forward compatibility on the long run. Commits ------- acac734 [PhpUnitBridge] new bridge for testing with PHPUnit