Rename test methods to always use camelCase about phpunit-data-provider HOT 7 CLOSED

We're not using snake_case() methods anywhere in the code, they're all camelCase().

from phpunit-data-provider.

@oliverklee Do you mean certain testcases names, like shouldCrossAssociativeArray_evenWithJaggedIterations()?

What's the problem with _, to make the test name clearer? It's still camelCase, just with additional separator.

from phpunit-data-provider.

@danon It's a violation of PSR-12, which is a superset of PSR-1, which requires all methods to be complete camelCase.

And it's not camelCase by definition if it has underscores in it. It's a mixture of camelCase and snake_case then. :-)

from phpunit-data-provider.

(And yes, I'm referring to the test method names.)

from phpunit-data-provider.

It's a mixture of camelCase and snake_case then. :-)

I don't think there is such a thing as mixture of camelCase and snake_case. Perhaps what you meant was that my testcase names dont' follow any naming convention? If so, then I agree, they don't :D

@danon It's a violation of PSR-12, which is a superset of PSR-1, which requires all methods to be complete camelCase.

I don't know about that. Testcases aren't regular methods, they behave in different way, and we require different behaviour of them. For example, shouldCrossAssociativeArrayEvenWithJaggedIterations() would be completely unacceptable as production code method name, but is fine as a testcase name.

I don't think we should use the same rules for production method names, and testcase names.

@oliverklee Are you 100% sure that PSR-12 recomendations are also supposed to be taken into account in automated tests? Isn't it only supposed to apply to production code? I read PSR-12 specification and I didn't find any reference to unit tests.

from phpunit-data-provider.

@danon First some general thoughts concerning the big picture:

It's your project, and in the end, it's your decision. :-)

What I'm trying to do here (in addition to giving back to a project I'm using) with my contributions is to help this project live long (and prosper ;-) ), and to be more reliable so we can rely on it in the Emogrifier project in the long term. I do this by making the project easier to contribute to, and by adding tools that help find flaws, and that also help prevent new flaws from getting introduced by PRs.

Now, concerning PSR-12:

You're not required by law in any way to make your projects PSR-12 compliant. :-)

Instead, PSR-12 mostly is about making the code more consistent (with itself and with other projects) so that contributors can rely on what they already know concerning styling, naming, and directory structure (which makes contributing easier).

PSR-12 is not limited to production code, but instead can be used for all code (and test code is code as well).

The more exceptions you make from the "use the full PSR-12 rule set for the full code" approach, the more specials things contributors need to keep in mind when contributing, which makes contributing harder. And having different coding standards for different parts of the code increases the mental load even more. (And it's also more work setting up the tools if we deviate from the default conventions).

And if you decided to not have your test code follow PSR-12 at all, that would also mean that we cannot use tools like PSR_CodeSniffer to enforce the coding style for test code in the CI builds.

So, I strongly recommend to keep as closely to the conventions of PSR-12 (code style), PSR-4 (autoloading) and the default configuration for PHPStan as possible. Still, in the end, it's your decision.

from phpunit-data-provider.

Yea, ok.

So we can step down from conveying meaning a bit, to step up similiarities in a code a bit. Let's go for it.

We just need to make sure all test names still make sense without the _.

from phpunit-data-provider.