Documentation omits support for mocking static methods about phpunit-documentation

[sebastianbergmann]

My blog was a blog, not a bliki. So no, I will not go back and update the blog post you mention. The proposed alternative is to not use static methods.

[sebastianbergmann]

I would rather remove the feature (it does not do what most people expect anyway) than document it.

[edorian]

👍 On throwing that out

[sebastianbergmann]

Can we do that in PHPUnit 3.8 already?

[edorian]

I'd say it should throw deprecation notices for one release?

[sebastianbergmann]

Makes sense. So we'll deprecate it in PHPUnit 3.8 and remove it in PHPUnit 3.9.

[whatthejeff]

Alright, I will close this in favor of deprecating the feature in 3.8.

[kevinburke]

@sebastianbergmann Could you update this blog post then explaining that this feature's deprecated, and/or proposing alternatives?

http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html

Thanks,
Kevin

[anthonybishopric]

Given that only newer versions of PHPUnit support the abstracted runtime environment (php vs hhvm), we are forced to upgrade to a version of PHPUnit that doesn't support static mocking. We have a large codebase and cannot just remove our static methods. What is your suggestion in this case?

[anthonybishopric]

Also, for what it's worth, it's odd that a feature that your users rely on is being removed in a minor version bump. Deferring the removal of this feature to 4.x would have more closely followed the guidelines set by semantic versioning.

[sebastianbergmann]

I am actually considering to rename 3.8 to 4.0 (and 3.9 to 4.1). But bumping the major version number does not solve your problem.

staticExpects(), which was slated for removal and marked as deprecated for a while, did not actually allow stubbing and mocking arbitrary static method calls. It only worked within the scope of the same class. Since it was limited in use I have rarely seen it being used. And considering that it provided little gain but considerable maintenance pain we decided to remove it.

[anthonybishopric]

Understood that the intended use was only when using static resolution within the same class, however it was always possible to inject the classname of mocked objects, as we have done and were able to mock arbitrary static methods. I know this will make you cringe, but it was something we relied on:

//

// in the code under test
$TheClass = ClassTable::find("TheClass");
return $TheClass::myStaticMethod();

// in the test itself
$obj = $this->getMock("TheClass");
/* ... set up static expectations ... */
ClassTable::set("TheClass", get_class($obj));

This was the only way to test some of our most procedural code and was a lifesaver. Obviously in an ideal world we wouldn't have this problem since we'd only ever be using non-static methods, but we aren't in that world and need this feature for the foreseeable future. However, I understand that we may have been relying on unsupported behavior in PHPUnit.

[anthonybishopric]

Might it be possible to backport the environment / runtime stuff to 3.7?

[sebastianbergmann]

Everything is possible (technically). But the 3.7 branch is closed for anything but bugfixes.

[ebeyrent]

So I guess we now aren't supposed to test static factory methods?

[Paxa]

After it removed, is there any way to stub static methods now?

[sebastianbergmann]

No.

[timbrownsf]

It feels gross, but it's something. You can use an inheritance approach, e.g.:
In Experiment.php

class Experiment
{
    public static function getVariant($userId, $experimentName) 
    {
        $experiment = self::loadExperimentJson($experimentName):
        return $userId % 10 > 5;  // some sort of bucketing
    } 

    protected static function loadExperimentJson($experimentName)
    {
        // ... do something
    }
}

In my ExperimentTest.php

class ExperimentTest extends \Experiment
{
    public static function loadExperimentJson($experimentName) 
    {
        return "{
            "name": "TestExperiment",
            "variants": ["a", "b"],
            ... etc
        }"
    }
}

And then I would use it like so:

public function test_Experiment_getVariantForExperiment()
{
    $variant = ExperimentTest::getVariant(123, 'blah');
    $this->assertEquals($variant, 'a');

    $variant = ExperimentTest::getVariant(124, 'blah');
    $this->assertEquals($variant, 'b');
}

[SvenRtbg]

@timbrownsf No, you can't, if you are calling the static method with self:: - this will always reference the class itself, not respecting any inherited class. You'd have to use static:: instead - and that is what this useless discussion is all about. Sebastian had a feature allowing to mock static functions that are being called using static::, but the world thought it would allow mocking calls made with self::, which it did not. While it was a nice idea trying to help test untestable code, he said he has seen very few useful usage, and much wrong usage - that's why the feature went out again.

[jannikkeller]

So there is absolutely NO way to test static methods with the most recent version of PHPUnit?

[SvenRtbg]

You can test them. You cannot mock them. That's why using static calls is bad for testability.

Am 29. Mai 2016 20:33:36 MESZ, schrieb jannikkeller [email protected]:

So there is absolutely NO way to test static methods with the most
recent version of PHPUnit?

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#77 (comment)

[sebastianbergmann]

This is not a support forum, sorry.