Provide a verbose mode for SimpleTest

This could use some design/visual work, IMO. Like, what's up with the square brackets? :P

There is a bug here:

return $i++;

doesn't return an incremented value of $i;

Nice work! This is a good start in something I think is REALLY important. There is no way to practice TDD the way things are currently setup. Perhaps a better way though would be to ditch the progress bar entirely, OR be able to show the output below the progress bar as it is running. The [verbose message] is a little too hidden for me. I want to edit, debug, go, edit, debug go without clicking around to see my debug message. I'd prefer to just see it inline personally.

If I want to develop from a test, I want to be able to print to the stdout buffer I think. If you use something like junit or ruby::unit, they just spit out to stdout. I don't see why what we've got is an advantage unless you are trying to run every unit test, every time you hit save, which IMO is an impossible way to code.

@bombatower:

function t_i() {
  static $i;
  $i = 0;
  return $i++;
}

for ($j = 0; $j < 10; $j++) {
  echo t_i($j);
}

That should explain what I meant. There is a bug, trust me.

Thanks for looking into this, I'll continue to use it and give reviews from time to time, but too busy to help much at this point.

d'oh, my bad. Must have had something funky in my install, but this wasn't what was needed to fix it.

-J

There is no way to practice TDD the way things are currently setup. Perhaps a better way though would be to ditch the progress bar entirely, OR be able to show the output below the progress bar as it is running. The [verbose message] is a little too hidden for me. I want to edit, debug, go, edit, debug go without clicking around to see my debug message. I'd prefer to just see it inline personally.

While I think the first sentence is an exaggeration, I see value in having something a bit more "streaming" so you don't have to wait for the test results. But as boombatower, mentioned, we can worry about that in a follow-up.

I still think the [verbose message] links are odd. I wonder if we just need to turn messages like: "Valid HTML found on "http://localhost/drupal-cvs/user/3" into links. Or whether we should add an icon somewhere.

While on the topic of that output, I find the 'Status' column to be completely redundant.

I've made some minor changes to the labels and committed it to CVS HEAD. Thanks!

Committed to HEAD.

This is sweet functionality. I turned it on and ran the comment tests and saw nice verbose links in the results. But when i click on the link, my firefox refuses to show the resulting page and safari nearly crashes on it. verbose.html gets huge fast. and it isn't valid html as it is just the body of an html page.

IMO, the logging should be done to separate files, one for each verbose invokation. And we should log to simple text files. the meta info should be in headers like email. that would scale much better. I know that some folks like "seeing" the HTML of the debug message in a browser by default but usually the caller just ends up doing a view source on that anyway. further, all HTML sent into verbose() has to be htmlspecialchars() beforehand. Really, text is best IMO. In any case, multiple files are needed. I can't imagine the hugeness of the file if it was enabled during a run of all tests.

I'm willing to write a patch if folks agree with my approach.

Agreed that the verbose mode is currently not usable in real life, brings browsers on their knees (at best).
Maybe we could just log the latest $this->drupalGetContent() only when a test fails ? (granted, that might be a completely unrelated request and you need to be a little smart when debugging; but the current implementation has the same "drawback": when debugging a failure, the latest drupalPost logged might be completely unrelated)

I'd find it extremely cool if we could preserve the current 'real HTML to see in a browser' feature, though - really more handy in a lot of cases to see whats wrong at once. If I need to investigate the markup, firebug remains my favorite primary tool anyway.

At any rate, separate files per logged page sounds a must.

well, it seems opening logged pages in separate tabs can compensate the 'scrolling through history' ?