Download the PHP package dave-liddament/phpstan-rule-test-helper without Composer
On this page you can find all versions of the php package dave-liddament/phpstan-rule-test-helper. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download dave-liddament/phpstan-rule-test-helper
More information about dave-liddament/phpstan-rule-test-helper
Files in dave-liddament/phpstan-rule-test-helper
Package phpstan-rule-test-helper
Short Description Library to help make testing of PHPStan rules easier
License MIT
Informations about the package phpstan-rule-test-helper
PHPStan rule testing helper
This library offers a couple of improvements to PHPStan's custom rule test harness.
This library provides AbstractRuleTestCase, which extends PHPStan's RuleTestCase
.
It offers a simpler way to write tests for custom rules. Specifically:
- No need to specify line numbers in the test code.
- You can specify the expected error message once.
Improvement 1: No more line numbers in tests
The minimal test case specifies the Rule being tested and at least one test.
Each test must call the assertIssuesReported
method, which takes the path of one or more fixture files.
Test code:
The fixture file contains the expected error message.
Fixture:
Every line that contains // ERROR
is considered an issue that should be picked up by the rule.
The text after // ERROR
is the expected error message.
With this approach you don't need to work out the line number of the error. This is particularly handy when you update the Fixture file, you no longer have to update all the line numbers in the test.
Improvement 2: Specify the expected error message once
Often you end up writing the same error message for every violation. To get round this use the getErrorFromatter
method to specify the error message.
Test code:
The fixture file is simplified as there is no need to specify the error message.
Any lines where an error is expected need to end with // ERROR
, the expected error message is taken from the getErrorFormatter
method.
Fixture:
The expected error messages would be:
- Line 6:
Can not call method
- Line 12:
Can not call method
The benefits of this approach are no duplication of the error message text. Any changes to the error message only need to be made in one place in the test case.
Adding context to error messages
Good error message require context. The context is added to the fixture file after // ERROR
. Multiple pieces of context can be added by separating them with the |
character.
Test code:
Fixture:
The expected error messages would be:
- Line 6:
Can not call Item::updateName from within class SomeCode
- Line 11:
Can not call Item::remove from within class SomeCode
More flexible error messages
If you need more flexibility in the error message, you can return an object that implements the ErrorMessageFormatter
interface.
In the example below the message changes depending on the number of parts in the error context.
NOTE: This is a contrived example, but it shows how you can use ErrorMessageFormatter
to create more flexible error messages.
Fixture:
The expected error messages would be:
- Line 6:
Can not call Item::updateName from class SomeCode
- Line 11:
Can not call Item::remove from outside an object