On Tue, Oct 25, 2011 at 11:56 PM, Michael G Schwern <schw...@pobox.com> wrote:
> I keep looking at subtests and keeping thinking that if there wasn't a test
> count to manage, would we need subtests?  Do we need all that complexity?  If
> it's just about the test count, can it be managed a better way?

I find several benefits:

* Less visual clutter in non-verbose output
* Indentation of verbose output
* Test granularity

I rarely care about test counts anymore -- the overhead of updating
plan just isn't worth it to me.

> I understand wanting "blocks of tests" and the ability to make plans for just
> those blocks, but do we need a discrete test state for that?  For example,
> Test::Class provides most of what subtests provide without special support.

I would suggest looking at Test::Routine as well -- it has been a
god-send to me for testing Metabase and uses subtests.

> It occurred to me because most other testing systems don't have subtests.
> They have test methods, but those aren't treated as a sub-state of the test.

That might work under an assertion-type system, where tests within the
method are assertions and some harness is catching exceptions within
the test methods.  The downside of assertions is that the test method
dies on the first assertion and you get no information about whether
subsequent tests would have passed or failed.

> In essence, a "subtest" is nothing more than a block of tests with a name and
> it's own plan.

I wonder how many people are using subtests with a plan and how many
are replying on the implied "done_testIng" feature.

>  The special TAP formatting seems unnecessary.  I guess that's
> the real question, do we need the special TAP formatting or do we just need
> named test blocks with their own plan?

Because I really don't care about numbering, I don't really care if
subtests have their own numbers or just continue the number sequence.
I do like the visualization options of subtests and it would be weird
if the numbering "jumped" when subtests were not verbose.

-- David

Reply via email to