Lack of interest No way to destroy $app

[Sim]

Okay - so not exactly a bug, but there's currently no workaround that I can reasonably think of, so I'm going to call it one.

I am writing a unit testing framework for XenForo addons using PHPUnit.

Right now, I'm having to instantiate the application once per test class rather than the more flexible option of doing it once per individual test.

We really need to be able to destroy the application (ie unset \XF::$app) so that it can be reinstantiated during the next test.

Simply adding something like the following to the \XF class would probably do the trick:

    public static function destroyApp()
    {
        self::$app = null;
    }

 

[Kocal]

What about using Reflection as a workaround?

Something like this would work I think:

$reflectionProperty = new \ReflectionProperty(XF::class, 'app');
$reflectionProperty->setAccessible(true);
$reflectionProperty->setValue(null);

 

[TickTackk]

Even if you did manage to unset $app, there are few more issues

Problem #1: XF\Extension doesn't check if the class has already been extended (credit to @Xon for the right pointers)
Solution #1: What I ended up doing is directly extending XF\Extension class but because this is not really extendable via XF's class extensions system, the entire extension and em need to be overridden in the containers inside initializeExtra().

Problem #2: runApp() showing the output instead of just running the app and storing controller reply anywhere
Solution #2: Made it work by extending the runApp() to not send the response and by extending XF\Mvc\Dispatcher class like here.

Problem #3: Irreversible actions like handling attachments, push notifications, emails and a few more things which I might be missing.
Solution #3: Haven't looked into this

The first two are already kinda fixed for the test I wrote for my Developer Tools add-on and also included the ability to test controller reply. You can try it out from here. I should probably move the testing bits to a different repository to make it easier for other people to test their own code as well.

 

[Chris D]

This does indeed feel more significant than adding a single function to set a single property to null.

Not going to consider this a valid bug report right now but feel free to continue the discussion so it can be considered in the future.

 

[Sim]

@batpool52! - I'm not trying to unit test the entire framework.

I'm certainly not running runApp() - all I'm doing is initialising the XF environment and then selectively replacing (mocking) elements from the container so that I can exercise parts of my addon code in isolation, while still having access to the underlying XF framework.

I'm using the test framework from Laravel as a basis for what I'm doing - it's quite an elegant solution.

I'm not really looking to test controllers and HTTP functions - controllers should generally be handing off execution to services and repositories anyway.

Some integration testing would be good at some point (at which point controller output does become significant) - but that's beyond the scope of what I'm aiming to achieve right now.