You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PHPUnit executes setUp() and other @before methods on each test run, so with regards to the test (test*() and @test) methods they behave more or less like a constructor.
When analyzing test classes, Psalm and the PHPUnit plugin report the properties initialized in setup methods as not initialized in constructor.
$ composer show | grep psalm
psalm/plugin-phpunit 0.15.1 Psalm plugin for PHPUnit
vimeo/psalm 4.5.2 A static analysis tool for find...
$ psalm tests/ObjectTest.php
ERROR: PropertyNotSetInConstructor - tests/ObjectTest.php:11:13 - PropertyTests\ObjectTest::$object is not defined in constructor of Tests\ObjectTest and in any private or final methods called in the constructor (see https://psalm.dev/074)
private $object;
While it's technically true, it's irrelevant for the test cases. By the time when the test method is invoked, the property will be initialized.
It is possible to rework such tests to initialize the object explicitly for each test method but this is less convenient, more verbose and in fact invalidates the PHPUnit setup approach.
The text was updated successfully, but these errors were encountered:
An easy, albeit not 100% correct approach could be to suppress PropertyNotSetInConstructor when there's an initializer present (setUp() or @before), similar to how it's done for MissingConstructor.
This is what I'm about to do at the project level but you're right, it will suppress other issues than this. E.g. sebastianbergmann/phpunit#4307 which still exists for some other properties like $backupStaticAttributes and $runTestInSeparateProcess (to be reported to PHPUnit).
PHPUnit executes
setUp()
and other@before
methods on each test run, so with regards to the test (test*()
and@test
) methods they behave more or less like a constructor.When analyzing test classes, Psalm and the PHPUnit plugin report the properties initialized in setup methods as not initialized in constructor.
While it's technically true, it's irrelevant for the test cases. By the time when the test method is invoked, the property will be initialized.
It is possible to rework such tests to initialize the object explicitly for each test method but this is less convenient, more verbose and in fact invalidates the PHPUnit setup approach.
The text was updated successfully, but these errors were encountered: