chore: first step towards Psalm level 6#1554
Conversation
a0c8d06 to
28b6eb1
Compare
| </MethodSignatureMismatch> | ||
|
|
||
| <InvalidArgument> | ||
| <errorLevel type="error"/> |
There was a problem hiding this comment.
By adding this, we ask Psalm to apply this rule and report any errors found
| <InvalidArgument> | ||
| <errorLevel type="error"/> | ||
| <errorLevel type="suppress"> | ||
| <file name="src/Behat/Testwork/EventDispatcher/TestworkEventDispatcher.php" /> |
There was a problem hiding this comment.
These two files need to be excluded because they produce false positives due to the code that is needed to keep the bc compatibility for all Symfony versions
| $message = $this->translator->trans('snippet_context_choice', array('%count%' => $suiteName), 'output'); | ||
| $choices = array_values(array_merge(array('None'), $contextClasses)); | ||
| $default = 1; | ||
| $default = '1'; |
There was a problem hiding this comment.
$default needs to be a string
| * @param string $class | ||
| */ | ||
| public function __construct($message, $class) | ||
| public function __construct(string $message, string $class) |
There was a problem hiding this comment.
doc-block was wrong, I changed it to use php types
|
|
||
| $result = $newResult; | ||
| $definitions[] = $newResult->getMatchedDefinition(); | ||
| $matchedDefinition = $newResult->getMatchedDefinition(); |
There was a problem hiding this comment.
getMatchDefinition() can return null, we need to check this and only add to the list of definitions if its not null
| $this->exampleSetupPrinter->printSetup($formatter, $event->getSetup()); | ||
| $this->examplePrinter->printHeader($formatter, $event->getFeature(), $this->example); | ||
|
|
||
| $this->example = $event->getScenario(); |
There was a problem hiding this comment.
We need to make sure that the ScenarioNode returned by getScenario() is an ExampleNode
There was a problem hiding this comment.
The structure of the way the event listeners is registered is somewhat complex, but I think the assumption is that events only reach this listener if we're in the course of running an Outline and therefore the scenario should be an ExampleNode?
If so, getting an unexpected type of ScenarioNode here would suggest either there's a problem with our event binding, or with our assumptions about how the nodes / events are structured.
In which case it might be better / safer to throw an exception (and hopefully fail CI) rather than silently not print anything? This would be the intentional version of the current behaviour where it will hit a TypeError.
| $totalCount = 0; | ||
| } else { | ||
| $totalCount = array_sum($stats); | ||
| $totalCount = (int) array_sum($stats); |
There was a problem hiding this comment.
$totalCount needs to be an int
| $style = $this->resultConverter->convertResultCodeToString($resultCode); | ||
| $hook = $callResult->getCall()->getCallee(); | ||
| $path = $hook->getPath(); | ||
| $hookName = (string)$hook; |
There was a problem hiding this comment.
We make the conversion to string explicit
There was a problem hiding this comment.
| $hookName = (string)$hook; | |
| $hookName = (string) $hook; |
To ensure code style consistency :)
| * Returns counters for different scenario result codes. | ||
| * | ||
| * @return array[] | ||
| * @return int[] |
There was a problem hiding this comment.
doc-block was wrong
| } | ||
|
|
||
| private function bcAwareDispatch(object $event, $eventName) | ||
| private function bcAwareDispatch(?object $event, $eventName) |
There was a problem hiding this comment.
$event can be null
| use Behat\Testwork\Event\Event; | ||
| use Behat\Testwork\Output\Formatter; | ||
| use Behat\Testwork\Output\Node\EventListener\EventListener; | ||
| use phpDocumentor\Reflection\DocBlock\Tags\Example; |
| * Returns counters for different scenario result codes. | ||
| * | ||
| * @return array[] | ||
| * @return int[] |
There was a problem hiding this comment.
I suggest documenting this as array<TestResults::*, int> to be more precise about the array keys.
| $style = $this->resultConverter->convertResultCodeToString($resultCode); | ||
| $hook = $callResult->getCall()->getCallee(); | ||
| $path = $hook->getPath(); | ||
| $hookName = (string)$hook; |
There was a problem hiding this comment.
| $hookName = (string)$hook; | |
| $hookName = (string) $hook; |
To ensure code style consistency :)
| $style = $this->resultConverter->convertResultCodeToString($resultCode); | ||
| $hook = $callResult->getCall()->getCallee(); | ||
| $path = $hook->getPath(); | ||
| $hookName = (string)$hook; |
There was a problem hiding this comment.
| $hookName = (string)$hook; | |
| $hookName = (string) $hook; |
Same here.
There was a problem hiding this comment.
Updated, thanks!!
7d05e69 to
53a1a43
Compare
acoulton
left a comment
There was a problem hiding this comment.
Good work @carlos-granados just a question about how best to handle unexpected types
| $this->exampleSetupPrinter->printSetup($formatter, $event->getSetup()); | ||
| $this->examplePrinter->printHeader($formatter, $event->getFeature(), $this->example); | ||
|
|
||
| $this->example = $event->getScenario(); |
There was a problem hiding this comment.
The structure of the way the event listeners is registered is somewhat complex, but I think the assumption is that events only reach this listener if we're in the course of running an Outline and therefore the scenario should be an ExampleNode?
If so, getting an unexpected type of ScenarioNode here would suggest either there's a problem with our event binding, or with our assumptions about how the nodes / events are structured.
In which case it might be better / safer to throw an exception (and hopefully fail CI) rather than silently not print anything? This would be the intentional version of the current behaviour where it will hit a TypeError.
| if ($example instanceof ExampleNode) { | ||
| $this->exampleRowPrinter->printExampleRow($formatter, $this->outline, $example, $this->stepAfterTestedEvents); | ||
| } |
There was a problem hiding this comment.
Same observation as the other Outline-related listener above, I think perhaps we should throw?
There was a problem hiding this comment.
I've updated the code to use assertions, which is what PHPStan recommends for this kind of type narrowing. What do you think?
There was a problem hiding this comment.
That looks like a good solution to me
acoulton
left a comment
There was a problem hiding this comment.
Great, thanks @carlos-granados
We should be increasing our Psalm level. Moving to error level 6 produces more than 100 errors, so, to make this more manageable, we can introduce the level 6 rules in small batches. This PR introduces one of these rules with the corresponding needed changes