FriendsOfPHP / PHP-CS-Fixer / 13731 / 8
82%
master: 93%

LAST BUILD BRANCH: phpdocAlignFixer
DEFAULT BRANCH: master
Ran
Files 283
Run time 9s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 79.83%. Remained the same
COLLECT_COVERAGE=1 SYMFONY_DEPRECATIONS_HELPER=weak

push

travis-ci

keradus 
minor #3444 IntegrationTest - ensure tests in priority dir are priority tests indeed (keradus)

This PR was squashed before being merged into the 2.2 branch (closes #3444).

Discussion
----------

IntegrationTest - ensure tests in priority dir are priority tests indeed

In current state, this PR is expected to fail.

Raised by https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/3436#discussion_r161375420 .

We do have integration tests. What for ?
Sometimes we are not sure how 2+ fixers would play together, so we do make an integration test between them.

Integration test runner is smart enough to double check priorities:
 - if priorities are the same, the expected outcome must be the same regardless of order that fixers would be applied,
- if priorities are different, we don't care.

Now the same, but from fixed code point of view:
- if `$fixedInputCode === $fixedInputCodeWithReversedFixers`, then priorities doesn't matter,
- if `$fixedInputCode !== $fixedInputCodeWithReversedFixers`, then priorities have to be different.

This is all what matters for end-user.
This is all that's needed to be stable, and whenever 2+ fixers becomes priority-related or stop being one, the tests are checking they are still running together.
This is all that is needed for devs writing custom rules.

-------------------------

Now, at this repo we went one step forward.
We do know by heart that some of the fixers have priority conflicts and we created auto review for them that checks explicit priority and fact that priority itest exist, as addition to itest itself (ref `\PhpCsFixer\Tests\AutoReview\FixerFactoryTest`).
It was super important at beginning (and still important, yet not that much), when we basically didn't have any itest at all. This explicit priority comparison was the only point when we were checking the order of fixers is what we assumed, even when it was not tested by itest.

Now, theoretically, we could drop distinguishes between `misc` and `priority` itests, then we shall reject this PR, or we could keep it and finish this PR.
There is a lot of boilerplate added in this PR that allows itests to be extended even more, yet don't focus on the implementation yet, first let us discuss the idea behind this PR.
To ease what is a real change, I assumed we are using `tests\test` as external package that have to be generic, and adjust project-specific tests in our `IntegrationTest` directly. I also added 2 notes to put focus on that few lines that are project-specific.

Also, keep in mind that apparently not all of `priority` tests are passing new check, what is proving that they (the few that are not passing) are not priority tests in the end...

Commits
-------

b6a9c1e5 IntegrationTest - ensure tests in priority dir are priority tests indeed

7496 of 9390 relevant lines covered (79.83%)

25.74 hits per line

Source Files on job 13731.8 (COLLECT_COVERAGE=1 SYMFONY_DEPRECATIONS_HELPER=weak)