Michael G Schwern wrote:
Disabling tests for subjective reasons (they take too long, they don't
test critical functionality, etc...) is a slippery slope.
I've seen this approach used successfully in a commercial setting. The
key is to make sure that the long tests do get run by someone.
If
Mark Stosberg wrote:
I'm looking at writing a test for an e-mail that's generated by Perl.
I'm wondering about the best way to do this.
A colleague of mine wrote fakesmtpd just for such an occasion -
http://www.jera.com/tools/fakesmtpd/. It's written in Perl.
--
Danny R. Faught
Tejas Software
Andrew Savige wrote:
Just curious, has anyone had STAF?
http://staf.sourceforge.net/index.php
I ran across STAF when I was researching freeware test harnesses, and I
recommended that my client evaluate both QMtest and STAF (they chose
neither of them, probably because they wanted commercial
I've often talked about the difference between my black-box test
experience and the unit testing context that most of you are working in.
I've come across an interesting example of an open source black-box
tool - QMTest, http://www.codesourcery.com/qm/qmtest.
QMTest has all the basic black
Ovid wrote:
I don't think much special work would need to be done. I've heard that Test::Cmd
works pretty
well. I was reading that just a few days ago, but I can't remember where I read that
(grr ...)
I mentioned it a few days ago because it designed to deal with
command-line programs, but I
What's wrong with creating these as subtests within a single .t file?
Are you trying to avoid that?
Have you looked at Test::Cmd? If I remember right, it's geared for
testing command-line applications rather than modules.
FWIW, the black box test harness I used to use allowed specifying an
66.67 50.00n/an/a
60.00
Total 66.67 50.00n/an/a
60.00
-- -- -- -- --
--
--
Danny Faught
Tejas Software Consulting
http://tejasconsulting.com/
