|
Re: TDD in perl
by chromatic (Archbishop) on Sep 19, 2003 at 17:13 UTC
|
I've written most of my code in that fashion for a couple of years. It really helps. (When I don't use TDD, I'm either experimenting with something really small to learn, or I'm about to screw up and learn my lesson again.)
You can use Test::Simple (and, even better, Test::More) for both unit (or programmer) and accentance (or customer) tests. The trick for programmer tests is to test individual pieces of your code, probably at the module level, if not the individual function and method level, in isolation, as far as possible. You want to be sure that what you're about to write does what it needs to do.
For programmer tests, you can use the same approach. You just have to think on a bigger scale.
For example, my Mail::SimpleList has a file called acceptance.t. It has just enough code to fake up an incoming message and just enough code to capture outgoing messages. The tests mostly boil down to sending a message a real user might send and testing that the responses are what should really happen. The guts of the modules (or how many modules there are) are hidden from the tests.
| [reply]
[d/l] |
Re: TDD in perl
by dws (Chancellor) on Sep 19, 2003 at 17:40 UTC
|
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).
| [reply] |
|
|
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] |
|
|
"...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] |
|
|
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] |
|
|
|
|
|
Re: TDD in perl
by simonm (Vicar) on Sep 19, 2003 at 17:06 UTC
|
The intents of the different kinds of tests aren't at all Perl-specific, so you could try looking at the definitions of these terms on some other sites.
For example, at C2, compare
Unit Test aka
Programmer Test against
Acceptance Test aka
Customer Test.
You can write both unit tests and acceptance tests using the standard Perl Test::* modules.
There are also several testing modules that are derived from the XP-style unit testing frameworks used in other languages; you may find these are helpful ways to structure your test code, but there's no requirement that you use them. A quick search found Test::Unit, Test::SimpleUnit, Test::Class, Test::Extreme, and I'm sure there are others. | [reply] |
Re: TDD in perl
by dda (Friar) on Sep 19, 2003 at 17:39 UTC
|
I have asked some questions on the subject recently:
And this is a collection of related nodes:
--dda | [reply] |
| A reply falls below the community's threshold of quality. You may see it by logging in. |