Filter scope when using PHPUnit's assertions

[lcobucci]

I'm not sure if this is the correct repo to open this issue, but it seems to be the best place...

What I'd like to implement (with some help, sure) is the ability to do the same thing done when assert() is called but when using PHPUnit's assertions:

https://github.com/phpstan/phpstan/blob/a50b95cb29fe720a3f8b35297fe3b559d6616d5a/src/Analyser/NodeScopeResolver.php#L197-L204

Some context:

We create contexts for Behat using PHPUnit's assertions and sometimes we have this kind of code:

public function thenSomethingMustHaveHappened(): void
{
    $something = $this->lovelyService->doSomething(); // which has `?Something` as return type hint

    Assert::assertNotNull($something);
    Assert::assertSame('Something', $something->getSomething());    
}

Then PHPstan complains:

------ -------------------------------------------------------------------------------------------------- 
  Line   SomethingContext.php                                                                     
 ------ -------------------------------------------------------------------------------------------------- 
  XX     Calling method getSomething() on possibly null value of type Something|null.  
 ------ -------------------------------------------------------------------------------------------------- 

However if assert($something !== null) is used, things just work...

Of course we could simply use assert() everywhere but we rather use a more friendly tool. So this leads us to two questions:

1. is this interesting for phpstan?
2. how can we implement this?

[ondrejmirtes]

Hi, this is a subject to a not-yet-existing extension point in PHPStan - I call it "Type-specifying extension" and there's already several issues open related to that: https://github.com/phpstan/phpstan/milestone/7

I'm gonna leave this open so we can return to that once that extension points exists.

[lcobucci]

@ondrejmirtes alright, thanks!

[Jean85]

I'm very interested in this too!
Since there isn't a "main issue" for this future extension, should we wait for its the creation?
Or it's possible to start/help with that?

[ondrejmirtes]

@Jean85 The first step would be to have a general extension point for these places:

• https://github.com/phpstan/phpstan/blob/master/src/Analyser/TypeSpecifier.php#L132 (this solves stuff like if (is_int($var)), but should be also able to solve method calls as well
• https://github.com/phpstan/phpstan/blob/b11df37ae17e3db4b7a2d4845145a81724256a36/src/Analyser/NodeScopeResolver.php#L176 (this is for direct influencing the scope without a condition, like assert())

So such an extension needs two mods somehow. I didn't get around to it yet because I don't have a great idea how the interface should look like 😊

[lookyman]

This should already work with master.

[ondrejmirtes]

It works if you call the methods on TestCase ($this->assert* or self::asert*) or as a function, which is also possible with PHPUnit!

[lcobucci]

@ondrejmirtes the context of this request was outside of a phpunit test case, is this alright addressed? If not, wouldn't it be more relevant to keep it open?

[lcobucci]

@ondrejmirtes I've just tested this with master and am curious why did you decide to not support Assert::assert*? Using PHPunit's functions is quite cumbersome because you have to manually add vendor/phpunit/phpunit/src/Framework/Assert/Functions.php to your autoload-dev in every project (which is not needed when using the static methods). BTW I'm using PHPunit 7.1.2.

Could you please link the commit(s) which solved this so that I can try to collaborate and have a more suitable solution for these specific needs?

[ondrejmirtes]

@lcobucci Yeah, Assert should also be supported, I misread the documentation. I just hope you're using it only in tests and not in production code, since PHPUnit should not be included in deployed code 😊

Implemented: 7048cb4

[lcobucci]

@ondrejmirtes awesome, thanks for your help! My use case is for behat contexts, so yes tests only 😄

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.