Can you explain why and why does it improve the tests? Thank you

• Although I haven't done any deep research maybe I am wrong on this I think this way you use less function calls
• My main argument here is readability and coding style. Shorter lines.. easier for the mind to adjust what the test are doing..

It would be great to have a php-cs-fixer rule to do that automatically. Otherwise, new code can enter the repo with the previous style and we're going to spend precious time from OSS contributors on that topic. (that's the typical downside of all CS-related PRs).
Would you like to contribute a PR to php-cs-fixer to do so?

Note also that this should target 3.4 (same as #29672)

@nicolas-grekas I have never looked into the code of php-cs-fixer but I will do it now and see if there is a chance to have it there... but I believe that this is a feature that it is really hard to implement on whatever fixer that does not do static analysis... it would require a lot of effort and that is because you can not totally ban returnValue neither equalTo since there are cases that are needed.

Furthermore, although I named it a 'codestyle' it is not exactly.. I guess both of us can understand what I mean here...

Yes... people can contribute the old style again on new PRs but has symfony been strict about this? I think no.. so there is no reason to be now... There is already some code with both ways... Most of it is with the previous way.. If you do want to be strict then this PR does not change anything.. if before you needed "X" amount of time in order to review and enforce equalTo now you will need the same "X" amount to enforce not to use equalTo.

With the current change "X" amount of time might be less since it provides readability and now days developers are not using these functions... Personally I haven't and most of the libraries that I've seen do not (maybe I am wrong again).

So concluding I kinda tend to think that developers that contribute to symfony see this old style and think that it is some kinda of rule... If you remove it from most of the files developers will use the new style as example and will contribute without using these function and even if they do contribute with the old style no harm is done...

Also I will change target branch...

@gmponos Thanks for working on all these PHPUnit related changes. I've merged the first one and created a related issue on PHP CS Fixer. But now that there is more, I think we really need to have these changes implemented in PHP CS Fixer first to avoid doing manual changes over time.

Thanks for working on all these PHPUnit related changes

I have many more coming 😄 .. I think that symfony tests deserve a little bit more attention.. I will try to create issues before proceeding since I see that they are raising some discussions... Hope that there is some spare time left for tests as well...

Look.. I understand that we all want to have things automated but it is not always possible. I have opened the related PR to php-cs-fixer but until then what? We can wait a while to see if this could happen on php-cs-fixer before merging this... but if it can not happen or if it takes too long for a PR to be submitted/merged then since there was not a strict rule about this before I don't see the reason why not moving forward... I understand the frustration none the less...

Anyway that's my point of view.

This is going to consume a lot of time from ppl in the core-team - both for reviewing and for merging.
This should not be taken lightly: this time is precious and we can wait to have a script do the job.

but I believe that this is a feature that it is really hard to implement on whatever fixer that does not do static analysis...

It is. Espically for cases like this it's rather token guessing:

-->with($this->stringEndsWith('results.html.twig'), $this->equalTo(array(
+->with($this->stringEndsWith('results.html.twig'), array(

Better use AST and static analysis.

I've noticed the issues and made a Rector rule to cover this.

Here is PR preview to Symfony I made rougly in 10 minutes: #29740
It found 934 lines to change, compared to this PR with 189 lines.

@gmponos Feel free to take it and use it. I have not intention to work on this, just make it much easier :)

I'm going to close as this is a time-consuming PR with little practical benefits. Generally speaking, all CS-related fixes should come via automated rules implemented in php-cs-fixer, to minimize the effort of maintainers.
Thanks for opening anyway!