So out of curiosity, is there any benefit to this in terms of practical usage? PHP's goofy in that it allows you to call static methods using OOP type syntax. Obviously there are cases where it just makes sense to call the method statically (i.e. you don't need to externally instantiate a new object instance as could be done with some of these JAccess things), but from a preference perspective I've never been a fan of $foo::bar().

@mbabker IMHO since we are testing static methods, we should call them the correct way. Also, this way someone reading the code knows that it is a static method being called. It just seems right.

Then you've honestly got a lot to do because all of the $this->assert* calls are to static methods ?

Honestly, I think this is just one of those preference things. When you've already got an object, using a static accessor like that looks really goofy (and without tweaks in PHP syntax you end up with issues, see the Travis report on that). In cases where you don't already have an object or don't need an object, I'm all for the static method calls being made correctly.

$foo = new Foo;

// Case 1
$foo->bar();
$foo::car();
$foo->far();
$foo::$jar;

// Case 2
$foo->bar();
Foo::car(); // or $foo->car();
$foo->far();
Foo::$jar;

To me when reading Case 1 it's just too easy to get yourself confused on what's going on. Case 2 to me is much more readable and seems less error prone.

? yes, I see your point, but those are the methods of PHPUnit - won't/can't do anything for those.
But I can do for the ones being tested.

@mbabker Sorry, didn't reply on your second half of your comment.
Yes, you're right.
However, since in most of the tests, the class where this method is called from, is changed depending on the inheriting test class, the options are these:

1. call the static methods appropriately (by moving the affected test-methods from the parent to the subclasses and calling the tested methods like Foo::bar() correctly there, instead of using the varying object.)
2. leaving it, as it is, with the changes of the current commit of this PR
3. Scrap this PR

For TestCaseCache it needs that dynamic element, no argument there (otherwise why bother with a generic test case most of the cache adapters can inherit?)

For the stuff in the application classes, I'd just change it to JApplicationX::getRouter() as we know what class is being tested there and what the expectation should be, I don't think there's any reason to call it as $object::getRouter() there.

For the JAccess tests, I'd just remove instantiating a new instance of the class in full and call those as JAccess::xx() as everything in that class is static so we're just wasting cycles instantiating an object just to call its method for testing (in a way that doesn't match production use at that).

For the most part, unless there is a critical need for a dynamic base object to call a specific static method, I think we're better off just calling it using the full class name. There are honestly only a few cases where a subclass might have an extended version and subclasses don't need to test the parent methods if they aren't extending them in any way.

Looks fine after the two inline comments are addressed.

?