nadim khemir wrote: > I spend a rather large amount of time writing and running tests. There are a > few things that could be better. I either don't know how or it may not > possible. I thought we could share some of questions and ideas that can make > working with tests more pleasent. This should go into a Q&A I guess.
Much of what you bring up here has been or can finally be addressed with Test::Harness 3, which was just released, and its underlying TAP::Parser. > - 'list of failed' is not very usefull > > Failed Test Stat Wstat Total Fail List of Failed > ------------------------------------------------------------------------------- > t/010_shared_variables.t 1 256 12 1 11 > > Scroll up, look at the errors, scan the text for a line number, fix the > error. > The error index given in the summary is almost never used. Test::Harness 3 has a revamped summary. It's open to more work and the code is finally sane. > I think it would > be better to get the test line. Is there a way to do that in the current > harness in the future harness? Yes, the information can finally be made available to the harness in a parsable form and Test::Harness can finally do something with it. See http://search.cpan.org/dist/Test-More-Diagnostic > - Colors in test outputs: > TAP::Harness::Color is nice but Module::Build doesn't use it. Has someone > plans to put it in? As TAP::Harness::Color is experimental, no. However, the way formatters work in TAP::Harness is still being worked on. > - Too much output: > My desktop is my IDE (sometimes my terminal is my IDE) and I like it that > way, > IDE's are too often in the way (or eating 1 GB of memory and cpu cycles > (Eclipse)) but I must admit that when there are lots test of failures I would > have liked to see the test results organized instead for having a thousands > of lines dump. How do you guys cope? I start at the top, read the first few failures, fix them and rerun. I ignore the bulk of a really large failure as they're probably just cascades of the one mistake. With TAP::Parser you finally have the ability to write your own displayer. > - Coverage per test: > Is there a way to get that? Dunno. > -Idea: I, sometimes, write my code in the test files. > > ->>>> > file A.pm: > > package A ; > sub s1 { s2() } ; > > > file t/00X_test.t > > package A ; > > use Test::More ; > sub s2 { ......, diag, .....} > > > package main ; > > # all the usuall testing > -<<<< > > That's very handy but it also shows a pattern. Debugging code that has tests > versus debugging code that you would normally run or run in the debugger. I > don't want to have yet another framework, everything is setup in the test but > the test steals my output so I have to 'diag' things out. Any other way you > know of? I don't get it. -- Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett
