Re: Test case modularity

Alexandre Ferrieux wrote:
> This means that every extension of an ensemble in the core needs
> fixing test cases that are completely unrelated to the new subcommand:
> tests expecting the message
> 
>     bad subcommand "foo": must be a, b, c, or d.
> 
> must be updated to check for
> 
>     bad subcommand "foo": must be a, b, c, d, or e.
> 
> Is there a good reason to do so ? Why not [regexp {^bad subcommand}] ?

I've wondered about that in the past too. I'm not sure; perhaps it is
wiser to allow the checking that the list of subcommands is what it is
expected to be as it helps enforce coverage. But if you do want to do a
non-exact match, please do this instead:

   -match glob -result {bad subcommand "foo": must be *}

It's easier to read, and doesn't obscure what the string was when a
failure happens. A more complete example might be this:

   test chan-0.1 {bad chan subcommand} -returnCodes error -body {
       chan foobar
   } -match glob -result {bad subcommand "foobar": must be *}

Let's compare that with the traditional way of doing this (assuming
we're doing glob matching; regexps don't make this easier).

   test chan-0.1 {bad chan subcommand} {
       string match {1 {bad subcommand "foobar": must be *}} \
               [list [catch {chan foobar} msg] $msg]
   } 1

I think the new-style one is clearer, especially when things go wrong!
YMMV (but I hope not...)

Donal.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08