-
-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for url() helper method #179
Conversation
What's up with StyleCI's strange conventions for imports? (analyses: https://github.styleci.io/analyses/q2RoxB) |
Very nice job. |
Nice PR! For the Tests though, you can get away with a bit less mocking (which is always better to prevent changes in PHPStan from breaking the tests), have a look at how we did it here: https://github.com/lxrco/phpstan-laravel/blob/master/tests/HelpersReturnTypeExtensionTest.php |
I see the same amount of mocked objects in the test you referenced. Am I missing something? The only (big) difference is the use of a data provider, which I didn't find suitable because there are different assertions for both return types. (In case of ObjectType it also performs an assertion on the object type, which is not the case for the string return type). |
And maybe the copyright needs changing: https://travis-ci.org/nunomaduro/larastan/jobs/445860198#L674 |
@szepeviktor I've added the copyright notice. Perhaps consider mentioning that requirement in Contributing? |
Okay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This Pull Request is perfect. The only thing that should be discussed: Testing should be addressed like this in Larastan?
I would prefer a feature
testing instead of unit
testing. Idea: Having a Laravel Project on the tests folder with the following code:
echo url('bla');
and url()->bla()
.
The test would be running Larastan on the level max
and if no errors happen then the tests passes.
Any feedback?
Thanks, @nunomaduro. I agree with you – I would also prefer behavioural testing over unit testing. Perhaps something similar to php-src's tests. Special files with PHP code in them, and also the expected (in this case PHPStan) output. But I'm not sure how easy that would be to implement. |
It’s easy, I will work on an example tonight ok? 🤙 |
@devfrey Just added tests for the |
Sure thing! |
The return type of the url() helper method is determined by the value of the first method parameter. If this parameter is null, an instance of UrlGenerator is returned. Otherwise, it returns a string.
I've added new tests! |
Thanks for this @devfrey ! |
Fixes #177
Since there were no unit tests covering the existing return type helpers, I gave it my best shot to write my own tests. Please let me know what you think.
Notes
This implementation only covers usage like this:
In theory, passing
null
as the first argument (directly or indirectly) would also result in aUrlGenerator
instance, but I was not able to implement a check for that.