cannot recognise trait methods

[miklcct]

I'm testing my codebase miklcct/thin_php_app and in two of the test files phpstan throws an error:

 ------ ------------------------------------------------------------------------------------ 
  Line   test/View/StreamToStringTest.php                                                    
 ------ ------------------------------------------------------------------------------------ 
  16     Call to an undefined method PHPUnit\Framework\MockObject\MockObject::__toString().  
 ------ ------------------------------------------------------------------------------------ 

 ------ -------------------------------------------------------------------------------- 
  Line   test/View/StringToStreamTest.php                                                
 ------ -------------------------------------------------------------------------------- 
  16     Call to an undefined method PHPUnit\Framework\MockObject\MockObject::render().  
 ------ -------------------------------------------------------------------------------- 

The mock objects are created by $iut = $this->getMockForTrait(StreamToString::class); and $iut = $this->getMockForTrait(StringToStream::class);, and the traits have the mentioned methods defined. PhpStorm type hints work on these 2 files.

[Stadly]

The workaround is to explicitly specify the type for the mock object.

/**
 * @var MockObject&StreamToString
 */
$iut = $this->getMockForTrait(StringToStream::class);

Related issue: #31

[ondrejmirtes]

Hi, traits are not valid types. I don't think that MockObject&StreamToString (in case StreamToString is a trait) does not resolve to what you think it resolves.

[Stadly]

I agree that a trait is not a type, but the workaround solved the issue for me, when I tried it. Hmm.

[ondrejmirtes]

"Solved" means that $iut is now an ErrorType which is basically mixed... I'll add a detection in the next version.

[Stadly]

That was definitely not what I thought! Thanks for explaining :)

By detection, do you mean emitting an error that MockObject&StreamToString is not a valid type, or a detection that lets $this->getMockForTrait(StringToStream::class) magically have the declarations from StreamToString without it being part of the type? Both would be useful ;)

[ondrejmirtes]

Traits are not valid types: https://3v4l.org/LhXBH

So I don't plan to support them in the typesystem, so MockObject&StreamToString above a variable will emit an error. It already does in properties and function declarations: https://phpstan.org/r/730efd90-d0ae-4219-8b02-4903ca8c5f3b

I'd like to hear what's your usecase for getMockForTrait since you can't typehint the trait.

[Stadly]

My use case is testing functionality in a trait, but I can just typehint the interface that is (partially) implemented when using the trait instead. This might lead to false positives when something is declared in the interface but not in the trait, but I guess this is a better solution since it is actually a type. Or do you have a better idea?

I guess traits in the typesystem would be needed if the trait contained public methods that were not in an interface, but this is probably a good indication that things should be structured a bit differently. So I think I agree with your decision to not support traits in the type system.

This could probably be closed as wontfix, then?

[ondrejmirtes]

I think the best way to test a trait is to create a class under tests directory that uses the trait, and write tests for the class. Since getMockForTrait is able to mock your trait's methods, you can't rely on it. It would be the same as if you tried to test a class and the first thing you'd do is to get an instance using createMock...

Yes, this is a wontfix :)

[Stadly]

Good idea! Thanks for explaining. Do you use the same approach when testing abstract classes, to avoid testing on a mock object?

[ondrejmirtes]

If I used inheritance and traits extensively, then yeah, but I try to avoid those 😊

On Thu, 24 Jan 2019 at 11:56, Stadly ***@***.***> wrote: Good idea! Thanks for explaining. Do you use the same approach when testing abstract classes, to avoid testing on a mock object? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGZuKeANF-FTL5T3ON2LnCba84TUEMeks5vGZFfgaJpZM4YurwC> .

-- Ondřej Mirtes

[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.