in reply to TDD in perl

Where do the different categories of test fall under "Unit Test", "Acceptance Test", "System Test"?

First it helps to agree on definitions.

An "Acceptance Test" is typically written by a customer, or on behalf of a customer. Its purpose is to verify that the customer is getting what they asked for.

A "System Test" is typically written by the team (or sometimes by QA). Its purpose is to verify that the assembled system "behaves" (for some definition of "behaves" :) There's often a lot of overlap between a System Test and and Acceptance Test.

A "Unit Test" is written by an individual programmer (or a Pair, if you're doing Pair programming). It's purpose is to verify that some component of the overall system behaves according to specifications. Or, if you're doing Test Driven Development, the test can serve the additional purpose of exploring the API before actually coding. The higher-level tests might not care one iota about Unit Tests, which is fine.

Extreme Programming and Test-Driven Development have paid the most attention to Unit Tests, though the "Industrial Extreme Programming" offshoot (http://industrialxp.org/) adds Acceptance Tests to the mix via attention to testing user stories early in the process.

In Perl, Unit Tests are often built with Test::More or one of its predecessors. Acceptance Tests and System Tests, from my experience, are all over the map. There are some options on the horizon. FIT (the Framework for Integrated Testing) has two Perl ports; one on the web site, the other on CPAN (Test::FIT). FIT is aimed at providing a framework that allows stakeholders to express Acceptance Tests via HTML tables (which can be generated either by hand, by a Wiki, or from Excel or Word).

Replies are listed 'Best First'.
Re: Re: TDD in perl
by thens (Scribe) on Sep 22, 2003 at 11:55 UTC

    Well, I dug up more in the web and found these links very useful. I thought I will share it with you folks.

    • Test Driven Development mailing list
    • Test Driven Development By Example by Kent Beck available as pdf from the above mentioned YahooGroups File section.
    • Newsgroup comp.software.extreme-programming

    I will keep you updated as i find more docs.

    -T

[reply]
Re: Re: TDD in perl
by michaeld (Monk) on Sep 21, 2003 at 20:47 UTC
    "...often a lot of overlap between a System Test and and Acceptance Test."

    The way I see it, an acceptance test can test just part of the system (e.g. all input facilities, a certain interface, etc...), but is always performed by, or at least verified by, the end user.

    A system test should include all parts of the system, not just one or more sub-systems.
    As you stated, it's performed to find out whether the system behaves as a whole.

    Cheers,
    MichaelD

[reply]
Re^2: TDD in perl
by adrianh (Chancellor) on Sep 22, 2003 at 10:44 UTC
    Extreme Programming and Test-Driven Development have paid the most attention to Unit Tests, though the "Industrial Extreme Programming" offshoot (http://industrialxp.org/) adds Acceptance Tests to the mix via attention to testing user stories early in the process.

    I might be misinterpreting what you're saying - but Extreme Programming relies on acceptance tests just as much as unit tests. You can't do XP without them.

    The practices and values that IXP adds to XP are about dealing with the larger scale issues that are outside the scope of XP (things like readiness assessments, project chartering, etc.).

[reply]
      Extreme Programming relies on acceptance tests just as much as unit tests. You can't do XP without them.

      Quite true. What I meant to emphasise was that IXP explicity tests User Stories as part of the process. XP, at least as I've seen it practiced, tends to treat user stories as gospel. Only the downstream products gets sanity tested.

      By forcing stakeholders to be explicit up-front with their acceptance tests, some nonsense in stories gets shaken out early.

[reply]

        Belated response :-)

        What I meant to emphasise was that IXP explicity tests User Stories as part of the process. XP, at least as I've seen it practiced, tends to treat user stories as gospel. Only the downstream products gets sanity tested.

        What do you mean by "tests User Stories as part of the process"? Unless I'm missing something there aren't any IXP practices for testing code that aren't already in plain XP.

[reply]

In Section Seekers of Perl Wisdom