Simpletest should include exception data in reporting [#242069]

As per a conversation with Crell in irc:

Apparently during his work on database abstraction he's running into issues where exceptions are being thrown by his tests and the data is being lost, rather than captured and printed in the simpletest reporting. I think this has some crossover with http://drupal.org/node/214028

I think we should be breaking up tests by method, and executing each method within a try block, in the event an exception is thrown we should be printing $e->getMessage(), $e->getLine(), and $e->getFile() into the reporting.

If I can get a couple +1's on this i'll put it together. Opinions?

Comments

Comment #1

Crell CreditAttribution: Crell commented 3 April 2008 at 04:58

It should go without saying, but +1 from me. :-)

Comment #2

boombatower CreditAttribution: boombatower commented 3 April 2008 at 05:10

I'm +1 for this and the other issue. Since no one seems to want to comment on the other I may just commit it.

If anyone has any comments on http://drupal.org/node/214028 please post them.

My only question is will this show any backtrace or allow for that possibility. I have written a nice error handler for my previous PHP project that had a JavaScript drop-down to show backtrace and such. It was all configurable with a set of constants.

For instance it would show the actual lines of code related to the issue like many debuggers do. Some of this is related more to debugging and is out of the scope of this, but just curious how far you want to take this.

Probably just displaying the message, line, and file is sufficient as you stated.

Comment #3

Crell CreditAttribution: Crell commented 3 April 2008 at 06:27

I think for now just a decent debug dump would be a huge improvement. We can think about fancy javascripty stuff later if we want. The critical things to know are: What type of exception (the class type), the file, the line, the message, and *which* test actually caused it. Probably in that order, I suppose. For unit tests, the backtrace is probably not as useful. And if I do need it, then from that information I can easily throw my own try-catch into the appropriate test. Right now, I can't even tell which test is throwing an exception other than commenting them out one by one.

Comment #4

yched CreditAttribution: yched commented 3 April 2008 at 13:54

The Krumo library (already integrated by devel for dsm() and devel_themer) provides nice and spiffy JS.

Comment #5

boombatower CreditAttribution: boombatower commented 15 May 2008 at 01:13

Project:	SimpleTest	» Drupal core
Version:		» 7.x-dev
Component:	Code	» simpletest.module

Moving.

Comment #6

chx CreditAttribution: chx commented 25 May 2008 at 21:17

Priority:

Normal

» Critical

cos of DB TNG its critical.

Comment #7

Crell CreditAttribution: Crell commented 27 September 2008 at 05:10

I managed to kinda sorta not really work around this for DBTNG, but this really, REALLY needs to get fixed. Then I can remove all of my exception handling code from the DB unit tests. :-)

Comment #8

Damien Tournoud CreditAttribution: Damien Tournoud commented 27 September 2008 at 11:11

Status:

Active

» Fixed

This is already in.

Comment #9

Damien Tournoud CreditAttribution: Damien Tournoud commented 27 September 2008 at 11:18

For reference, this was fixed in #305077: Rework simpletest backend.

Comment #10

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 27 September 2008 at 15:47

@Crell: Also, I think your exception handling was removed too, as a result of the above patch. Might want to double-check that and file follow-up patches if not.