Generic/ArbitraryParenthesesSpacing: improve sniff code coverage

[rodrigoprimo]

Description

This PR improves the code coverage for the Generic/ArbitraryParenthesesSpacing sniff.

There was just one block of defensive code to protect against a parse error that was not exercised by the tests. I followed the instructions on #143 for creating parse error tests.

I also added the match expression to one of the test case files. The sniff was already handling it properly, but I thought it would be useful anyway to ensure it continues to handle it properly in the future.

Code coverage for the Generic/ArbitraryParenthesesSpacing sniff before this PR:

https://coveralls.io/builds/64633852/source?filename=src%2FStandards%2FGeneric%2FSniffs%2FWhiteSpace%2FArbitraryParenthesesSpacingSniff.php

And after this PR:

https://coveralls.io/builds/64658984/source?filename=src%2FStandards%2FGeneric%2FSniffs%2FWhiteSpace%2FArbitraryParenthesesSpacingSniff.php

Related issues/external references

Part of #146

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the Contribution Guidelines.
• I grant the project the right to include and distribute the code under the BSD-3-Clause license (and I have the right to grant these rights).
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added XML documentation for the sniff.

[jrfnl]

Thanks @rodrigoprimo ! And yes, I totally agree it's a good thing to add the test with the match expression.

For the parse error test, I probably wouldn't have used a code snippet with the function keyword as the sniff is explicitly excluding parentheses for function declarations, so I probably would have gone with something like $var = 1 + 3);.

Having said that, as it is an unbalanced parenthesis, the test as it is now will work fine as due to the unbalanced parenthesis, the tokenizer won't see the function keyword as the parenthesis owner.

I will merge this PR now without requesting changes. I just wanted to give you that feedback as input for future PRs.

[rodrigoprimo]

For the parse error test, I probably wouldn't have used a code snippet with the function keyword as the sniff is explicitly excluding parentheses for function declarations, so I probably would have gone with something like $var = 1 + 3);.

Having said that, as it is an unbalanced parenthesis, the test as it is now will work fine as due to the unbalanced parenthesis, the tokenizer won't see the function keyword as the parenthesis owner.

Makes sense. Thanks for the additional details. I will pay attention to this in future PRs.