How do you use PHPUnit to test a function if that function is supposed to kill PHP?

Question

Essentially I have a method of a class called killProgram, which is intended to send a hTTP redirect and then kill PHP.

How am I supposed to test this? When I run phpunit it doesn't return anything for that test, and closes completely.

Right now I'm considering having the killProgram function throw an exception which shouldn't get handled, which would allow me to assert that an exception was thrown.

Is there a better way?

Somaliland

in theory, register_shutdown_function might be able to provide a solution although I'm not too sure about the implications of doing so. – Wieldy

Answer 1

As every tests are run by the same PHPUnit process, if you use exit/die in your PHP code, you will kill everything -- as you noticed ^^

So, you have to find another solution, yes -- like returning instead of dying ; or throwing an exception (you can test if some tested code has thrown an expected exception).

Maybe PHPUnit 3.4 and it's --process-isolation switch (see Optionally execute each test using a separate PHP process) might help (by not having everything dying), but you still wouldn't be able to get the result of the test, if PHPUnit doesn't get the control back.

I've had this problem a couple of times ; solved it by returning instead of dying -- even returning several times, if needed, to go back "high enough" in the call stack ^^
In the end, I suppose I don't have any "die" anymore in my application... It's probably better, when thinking about MVC, btw.

Bobbysoxer

Yeah, right now I've decided to throw an exception. The problem is my default exception handler is intended to call this function, so I have to create a new exception called killProgramException which my exception handler ignores. Kind of hacky – Somaliland

Answer 2

My suggestion would be to move the code that die()'s into a separate method that you can then mock.

As an example, instead of having this:

class SomeClass
{
    public function do()
    {
        exit(1);
        // or
        die('Message');
    }
}

do this:

class SomeClass
{
    public function do()
    {
        $this->terminate(123);
        // or
        $this->terminate('Message');
    }
    
    protected function terminate($code = 0)
    {
        exit($code);
    }
    
    // or 
    protected function terminate($message = '')
    {
        die($message);
    }
}

That way you can easily mock the terminate method and you don't have to worry about the script terminating without you being able to catch it.

Your test would look something like this:

class SomeClassTest extends \PHPUnit_Framework_TestCase
{

    /**
     * @expectedExceptionCode 123
     */
    public function testDoFail()
    {
        $mock = $this->getMock('SomeClass');
        $mock->expects($this->any())
             ->method('terminate')
             ->will($this->returnCallback(function($code) {
                 throw new \Exception($code);
             }));

        // run to fail
        $mock->do();
    }
}

I haven't tested the code but should be pretty close to a working state.

Chancellor

Answer 3

There's no need to change the code just to be able to test it, you can simply use set_exit_overload() (provided by test_helpers from same author as PHPUnit).

Illassorted

Link for the lazy: github.com/php-test-helpers/php-test-helpers (Note that this is a PHP extension that you need to activate in your php.ini) – Coraleecoralie

Note: This project is no longer maintained (since 2014). – Occupation

Answer 4

Instead of using die(), you could use throw new RuntimeException() (or an exception class of your own), which will also halt program execution (albeit in a different fashion) and use PHPUnit's setExpectedException() to catch it. If you want your script to die() when that exception is encountered, printing absolutely nothing up at level of the user, take a look at set_exception_handler().

Specifically, I'm thinking of a scenario in which you'd place the set_exception_handler()-call into a bootstrap file that the tests don't use, so the handler won't fire there regardless of scenario, so nothing interferes with PHPUnit's native exception handling.

Koeppel

this answer basically suggests to use exceptions as flow control structures, which is generally not desirable. – Task

Answer 5

This relates to set of issues I've been having getting some legacy code to pass a test. So I've come up with a Testable class like this...

class Testable {
   static function exitphp() {
      if (defined('UNIT_TESTING')) {
         throw new TestingPhpExitException();
      } else {
         exit();
      }
   }
}

Now I simply replace calls to exit() with Testable::exitphp().

If it's under test I just define UNIT_TESTING, in production I don't. Seems like a simple Mock.

Planoconvex

this might look nice in the beginning, but this is changing the behavior of the program just for the sake of testing, which would not be nice in the end IMHO – Rastus

Answer 6

You can kill the script or throw an exception, depending on the value of an environmental variable...

So you kill in production or throw an exception in test environment.

Any call to die or exit, kills the whole process...

Gallenz