4

While using PHPUnit via the below code-snippet in Eclipse, I get the error:

Cannot send session cookie - headers already sent by (output started at C:\wamp\bin\php\php5.3.13\pear\PHPUnit\Util\Printer.php:172)

Session_start() is executed within "LoginTest". How can I stop PHPUnit from interfering with session cookie generation?

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
require_once 'C:\wamp\bin\php\php5.3.13\pear\PHPUnit\autoload.php';

class MyTestCase extends PHPUnit_Framework_TestCase {
     static function main(){
        $suite = new PHPUnit_Framework_TestSuite("LoginTest");
        //$suite = new PHPUnit_Framework_TestSuite("FriendListTest");
        //$suite = new PHPUnit_Framework_TestSuite("UserTest");
        PHPUnit_TextUI_TestRunner::run($suite);
     }
}
MyTestCase::main();
?>

Very similar problem with solution that won't let me debug in Eclipse.

Community
  • 1
  • 1
Garzahd
  • 5,739
  • 3
  • 18
  • 19
  • 1
    As with any system under test, you can not expect that the testing environment would work seemlessly with any code regardless which one. Your code obviously starts a session somewhere when it's too late. Switch to non-cookie sessions for your SUT. Non-Cookie sessions do not cause the header error. – hakre May 20 '13 at 19:42

3 Answers3

3

At the top of the problem unit test function (or if all functions are affected then in setUp(), or even public static function setUpBeforeClass()) add this code:

@session_start();

Or in long-hand:

$prev = error_reporting(0);
session_start();
error_reporting($prev);

It looks like something you should never do, but it is perfect here, because suppressing an error message was exactly what we wanted to do!


As I noted in a comment on hakre's answer, fiddling with ini settings never worked, not even trying this combination before calling session_start():

 ini_set("session.use_cookies",0);
 ini_set("session.use_only_cookies",0);
 ini_set("session.use_trans_sid",1);
Darren Cook
  • 27,837
  • 13
  • 117
  • 217
  • This works, but then you get the related warning that "a session was already started". In a phpunit testing situation, you can then just @suppress the login code in the testing suite to avoid having to deal with that (legitimate) warning killing your tests. – Kzqai Jun 03 '14 at 14:44
  • @Kzqai Yes, that is why the `@` sign is there, and important. – Darren Cook Jun 04 '14 at 01:48
  • This helps suppress the message `session_start(): Cannot send session cookie - headers already sent by ...`. However it will still produce an error on your tests. So this is not really a solution. – w00tland Jan 07 '16 at 11:02
  • @w00tland It was working (as in no error being given when running tests, all tests passed) at the time I wrote the post. I.e. with whatever version of PHP and phpunit I was using at the time. What version are you using? It could be something in phpunit has changed that now stops with hacky workaround working. Or it could've been some other error in your tests? – Darren Cook Jul 27 '17 at 14:08
3

Add the following to your phpunit.xml

<php>
    <ini name="session.use_cookies" value="0" />
    <ini name="session.use_only_cookies" value="0" />
    <ini name="session.use_trans_sid" value="0" />
    <ini name="session.cache_limiter" value="" />
</php>
Arnold Daniels
  • 16,516
  • 4
  • 53
  • 82
0

How can I stop PHPUnit from interfering with session cookie generation?

Most straight forward seems to not use cookies for the sessions:

http://php.net/session.use-cookies

hakre
  • 193,403
  • 52
  • 435
  • 836
  • This appears to not work. E.g. at the top of a unit test I've added: `ini_set('session.use_cookies', 0);session_start();` and I get the complaint about "headers already sent" on that line. Without the session_start() line I just get the same thing but deeper (i.e. in the code being tested). (I've not managed to get it work in both php 5.3.x and 5.5.x, and with different versions of PHPUnit too.) – Darren Cook May 01 '14 at 00:47
  • @DarrenCook: That's perhaps more than this setting, create an isolated test-case w/o php unit and check with cookie settings there. I don't have my large session test-suite here, so I would have double-checked so, but this should work. Probably it's more than the single named setting?! – hakre May 02 '14 at 15:34