Symfony-coding-standard

Symfony-coding-standard copied to clipboard

The Commenting\AnnotationsSniff currently doesn't like:

/**
 * @expectedException \Exception
 * @expectedExceptionMessage Don't do it.
 */
public function testThing() {}

But I don't think this looks right:

/**
 * @expectedException \Exception
 *
 * @expectedExceptionMessage Don't do it.
 */
public function testThing() {}

Could we add a blacklist for these? Possibly make it configurable?

you could consider aliasing your annotations?

/**
 * @Tests\expectedException \Exception
 * @Tests\expectedExceptionMessage Don't do it.
 */
public function testThing() {}

should be valid.

I didn't think that worked with phpunit's annotation parser?

i have no idea whether that's possible with phpunit's annotation parser tbh...

But I don't think this looks right

i don't think that's really the purpose of a coding standard and what you're basically asking is this coding standard to provide a way to break the rules based on sentiment.

of course feel free to create a pull request for this and try to convince @djoos of it's pupose, but personally i'm not in favour.

Take a look at Symfony's source; they never have a new line between those two annotations.

https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Console/Tests/ApplicationTest.php https://github.com/symfony/symfony/blob/master/src/Symfony/Component/DependencyInjection/Tests/Compiler/AutowirePassTest.php https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Process/Tests/ProcessTest.php https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Tests/Extension/TranslationExtensionTest.php

Hmmm, I must admit I wasn't originally in favor either, but that is a great point @CarsonF...

@CarsonF it looks like all your references point to test classes which clearly do not comply to a lot of standards (no class comment, no function comments, multiple classes in one file, etc.).

apart from that, if you have a look at the naming convention section of the coding standard, it's stated

Please note some early Symfony classes do not follow this convention and have not been renamed for backward compatibility reasons. However all new abstract classes must follow this naming convention;

so using the symfony source code as a reference to justify whether or not a sniff should be implemented might not be the way to go...

even though my personal opinion is that test classes should comply to coding standards as well, it's always possible to ignore those in your ci configuration