Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

PHPUnit disables xdebug #221

Closed
sgronblo opened this Issue · 11 comments

5 participants

@sgronblo

For some reason, couldn't for the life of me figure it out from the logs, phpunit checks if xdebug is loaded and then disables it if it is.

This makes PHP's super lame "fatal error" handling just spit out which line in your application does something which causes a "fatal error", with no indication which line in your tests caused that application line to be called.

@whatthejeff
Collaborator

xdebug_disable() is actually a bit of a misnomer. It really only disables stack traces. I think it's related to an old problem where Xdebug stack traces were breaking PHPUnit. I'm not really sure how relevant this is anymore since removing the call to xdebug_disable() doesn't break any unit tests as far as I can tell.

The accepted answer on stackoverflow is the best advice. Using --process-isolation will give you the stack trace you are looking for. Alternatively, If you just want to know which test triggered the error, you can use the --debug flag to print out the individual test names as they run.

@sgronblo

Ok, the --debug flag sounds like it would be a less cumbersome thing to try at first, compared to commenting out the lines for it in the phpunit script. But the nicest thing would be if whoever added it checked if it was necessary any more.

I guess this shows why commit messages that just repeat the commit are useless. For example, the message for the commit that adds the xdebug_disable line simply says: "Disable Xdebug stack traces for all error conditions." but without mentioning why.

@whatthejeff
Collaborator

I guess this shows why commit messages that just repeat the commit are useless. For example, the message for the commit that adds the xdebug_disable line simply says: "Disable Xdebug stack traces for all error conditions." but without mentioning why.

I can agree to that. Part of the problem is that PHPUnit used to be managed in a Trac project on phpunit.de. If you look at the original commit message, it mentions a Trac ticket number; but the Trac project is no longer online to cross reference.

@whatthejeff
Collaborator

@sgronblo is there anything else you need for this ticket?

@sgronblo

Well I have mostly been working with the sweet Python and Django recently so I haven't used PHPUnit in a while. I don't think I ever had time to test if --process-isolation solved my problem. Did someone manage to figure out why PHPunit disables Xdebug?

@whatthejeff
Collaborator

I guess if anyone knows it's probably @sebastianbergmann. Maybe if we ask nicely he can enlighten us :)

@sebastianbergmann

The problem is the xdebug.show_exception_trace configuration setting. When set to 1, this will "show a stack trace whenever an exception is raised - even if this exception is actually caught.". This behaviour breaks the output of PHPUnit.

Now if I remember correctly, Derick recommended using xdebug_disable(); over ini_set('xdebug.show_exception_trace', 0);.

@masi

Ist Derrick still around to answer why he argued against ini_set('xdebug.show_exception_trace', 0);? It seems to be a good solution (whithout any further knowledge).

@whatthejeff
Collaborator

Derick actually maintains the Xdebug project. The best venue for asking him questions about Xdebug is the mailing list.

@ktomk

With xdebug's default configuration I have no such output problems while not disabling xdebug in /usr/bin/phpunit. Just ran a couple of tests with catched and non-catched exceptions (text output).

Looks like it's not necessary to disable xdebug to not display the exception traces because the default configuration has them disabled anyway.

And Derrick can't remember giving a recommendation to favor xdebug_disable over the xdebug.show_exception_trace setting (which is 0 by default, see docs).

@greglamb greglamb referenced this issue from a commit in greglamb/phpunit
@sebastianbergmann Do not disable Xdebug and close issue #221. 968328d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.