The assertion methods are declared static and can be invoked from any context using PHPUnit\Framework\Assert::assertTrue(), for instance, or using $this->assertTrue() or self::assertTrue(), for instance, in a class that extends PHPUnit\Framework\TestCase.
A common question, especially from developers new to PHPUnit, is whether using $this->assertTrue() or self::assertTrue(), for instance, is “the right way” to invoke an assertion. The short answer is: there is no right way. And there is no wrong way, either. It is a matter of personal preference.
I see self::assert* more and more I even reverted some PR’s because of it to enforce consistency at least in the same package. Today I asked @mwop what to do in zendframework. This was his answer:
Whenever I see self::, I just change those to $this-> when merging.
So basically the PR’s are like a ping pong game. Some are changing it to self:: and the next PR others are changing it to $this-> and vice versa. self:: is used all over the place.
Without an official statement we can’t tell contributors what to use in their PR’s. And from experience I know a quote from a private slack group is not good enough to stop the discussion
I’d like to say only that I was defending $this->... for a long while, but recently I’ve started using self:: (as it is one character less, and easier to type :P)…
Definitely we should have consistency across all repositories, maybe even we should add it to coding-standard.
I would ping here @ocramius and @mwop because these two guys have different opinion (I guess :D). Thanks guys
Interesting: I do the opposite, changing $this-> to self:: while
merging.
Remember that the method is static, so static code analysis tools will
catch this as a violation at some point, and hopefully PHP will stop mixing
the two at some point in the future.
I run static analysis on test classes all the time: it finds parameter
mismatches, method signature issues, stub misuse and it prevents me from
writing impossible scenario tests
Remember that the method is static, so static code analysis tools will
catch this as a violation at some point
Really? Then I’d consider this an error in the static analysis tool. In PHP a static method can be called satically and non-statically, this is no logical error (since $this context does not apply to static methods, even if called non-static). Only calling non-static methods statically would be an error, since these require $this context. Sebastian states this: There ist nor right- or wrong-way to do it, just a matter of taste.
It is a mismatch in expectations: one is to call a function that may access
shared mutable global state, the other one is specific to the state of the
given object.
From a reader perspective, self:: is a strong indicator that the current
object state will not be modified, which is quite important. (yes, statics
that modify shared global state are bad!)
I’m in the self:: boat myself (recently converted). There is no point in adding to the confusion by calling a static method non-statically. Just call it what it is.
Actually I don’t mind how this will come out (As stated above, in PHP calling a static method non-statically does not matter).
But I’d like to raise awareness that a switch from $this-> to self:: would either result in inconsistent test-code or all components may need to be rewritten to use self::. Do we have the resources for this or can we live with the mixture for a while (or forever if nobody finds the time to contribute for a component)? Another thing is when a test expects an axception: This is done with $this->expectException() which is kind of an assertion that is not static. Also please note that the offical PHPUnit documentation shows all TestCase examples with $this->, so we might have to expect contributions with $this-> (e.g. https://phpunit.de/manual/current/en/appendixes.assertions.html#appendixes.assertions.assertCount).
Im all for ‘zelf::’. Actually went in and changed it until some maintainer started laughing really hard. So I shut up and thought nothing of it further.
The point with $this->sth is that its been used ever since, whereas self::sth has been invented out-of-nowhere just because sth had to change and developers had no idea what to chenge…
In other words => its been extremely stupid idea to introduce self::sth and force its usage by (progressively) making $this->sth deprecated…
And thats only one example of things invented because they have to invent sth… there are many more throughout PHP…
Whole Zend…
What I really miss much is pure PHP meaning from pre-Zend times… it was extremely nice programming language…
