in reply to What is a testing plan?

The Extreme Programming people say that the tests are the specification. In other words, if your code passes the tests, it is correct by definition. (Even if your tests are in fact incorrect. :) ). I usually don't write tests before I write code; I'm just not used to thinking that way, but when I do, I think in terms of a specification. What's this class supposed to do? What will its interface be? At the very least, let's assume it's a traditional OO Perl class with a blessed hashref implimentation and a constructor. That gives us some good information to start a simple test file: 

use strict;
use warnings;

use Test::More;
use_ok('My::New::Module');

my $obj = My::New::Module->new;
ok( $obj );
isa_ok( $obj, 'My::New::Module' );

[download]

We've already tested some very important things: We can load the module, the constructor returns a true value, and that value is an object of the type we've been expecting.

If you're the type of person who can plan your modules completely ahead of time, go ahead and write simple tests for each method that this object will have, making sure they return the correct values and alter the object's internal state properly.

Personally, I tend to develop modules and tests in parallel, writing a feature, making sure it works to my satisfaction, and then writing a test to make sure it continues to work that way. Sometimes I get lazy and don't write the tests until the very end.

The most important thing is not to get too bogged down in dogma. Experiment a lot and do what works best for you and increases your productivity. Don't worry yourself if you're not strictly adhering to "red, green, refactor." Development methodologies should be taken as advice, not instructions. You must always find your own way.

Replies are listed 'Best First'.
Re^2: What is a testing plan?
by Ovid (Cardinal) on Mar 02, 2006 at 21:25 UTC

    friedo wrote: The Extreme Programming people say that the tests are the specification.

    I see that a lot, but it always concerns me because I don't think it really holds true. Consider the following tests:

    can_ok $object, 'copy_for_xmission';
ok my $clone = $object->copy_for_xmission, '... and copying should be 
+successful';
isa_ok $clone, 'Some::Class';
ok !defined $clone->ssn,                   '... but the SSN should not
+ be copied';

    [download]

    It's very common to see that in tests and it's perfectly appropriate. Now in reading the test output, we can see that the SSN is not copied on clone, but we don't know why. There are plenty of reasons why we might not copy the SSN over, but the tests tend to reflect what is happening, not why it's happening. As a result, tests document behavior, not business rules.

    The problem with this is institutional knowledge. In many companies I've worked for, documentation is almost an afterthought. Some other programmer looking at this might can see the behavior, but when getting asked to extend or alter the behavior, they can easily make mistakes without an understanding of the underlying business reasons for the code's behavior. Programmers often claim that you should simply be able to read the code (or tests) to know what's going on but that ignores that the larger the system, the larger the number of assumptions which might creep into the code without explanation.

    Cheers,
    Ovid

    New address of my CGI Course.

[reply]
[d/l]
      As a result, tests document behavior, not business rules.

      But that's not quite what friedo said. He wrote that "the tests are the specification". A specification just describes behavior -- the reasons why that is the desired behavior provide helpful context for interpreting behavior or generalizing it to new situations, but they aren't the specification itself.

      Assumptions creep into code because requirements are rarely well-specified. Therefore, they become open to interpretation -- which is why having that context and institutional knowledge documented becomes important. All TDD does is encourage developers to be explicit about how they are interpreting a requirement or specification, before they write the code.

      When people say tests or code are the documentation -- it's a limited form, but it has the advantage over other types of documentation that they are, by definition, describing what actually happens, rather than what was desired or intended, which which may or may not have been updated and which the program may or may not fulfill. But that's still just a documentation of the spec, not the requirements.

      What I find, personally, is that TDD helps brings focus. It's not a documentation technique; it's a task-management technique. There's a clearly defined concept of "done" and the code I write is limited to achieving "done" as directly as possible. The clarity of thinking through how to prove that something does what I expect also usually means that by the time I write actual code, I have a much better idea of what I need to write. That, too, saves time and improves the quality of what I write.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]

In Section Meditations