Writing tests is a pain in the backside. If you are to write a good test suite you obviously need to test the algorithms used in your methods - that is, make sure that it returns the right results. But you also need to test that your code fails correctly. Given that you are a good programmer, you will have documented all your failure modes. I find that my code always has far more ways of failing than of succeeding, and that most of those are due to the programmer supplying bogus arguments to my methods. I might document a simple method like so (taken from a user/group management application: 
=item addgroup

Takes one parameter, which may optionally be named 'group'.
We detect whether it is a named parameter or not by checking
for the presence of 'group' followed by anything else in the
arguments.  This should be a valid groupname (ie consists
solely of word characters) which does not exist.  If that's
OK, an empty group is created.  All errors are fatal.

[download]
So let's see what are the failure conditions here:

There is one way of succeeding - if none of the above apply, an empty group is created. And if any of the above apply, we die().

I want to do as much as I can to automate the writing of my tests. Clearly, I can't automate writing tests for success, but I feel that I should be able to at least go part of the way towards automating tests for failure.

I would like to embed those tests in the POD in such a way that I can use a tool to both spew out a skeleton for the tests to which I can later add tests for success and for any other failure conditions which can't be easily specified (eg, in this case the test for "user specified a group that already exists"); and also the same data that was used to generate those tests will also generate human-readable documentation. I'm prepared to accept human-readable docs that are somewhat stilted.

There is already Test::Inline on the CPAN, but that doesn't go far enough - it lets me write my tests inline with the POD, but does not attempt to generate them automagically.

I'd like feedback on whether people think this is a good idea, and on the sort of syntax I should use.

Replies are listed 'Best First'.
Re: Automatic generation of tests
by flyingmoose (Priest) on Feb 23, 2004 at 14:12 UTC

    Test cases (more specially test suites) need to be written in actual code, if they must be documented, document above the test case using POD.

    Why? Because you need to run them. Use of any language that is not Perl to write the tests will result in your tests being less flexible than Perl, meaning you are probably going to drop some corner cases through use of some meta language. The group example you gave was rather simple to test, but many things will be much harder. Suppose, for instance, that you have a complex simulation, tons of equations, or (dunno) some sort of ray-tracer. Can you write tests for that in some alien syntax? Probably not.

    I just looked at Test::Inline, and (to be fair) the syntax is a little ugly to me. Why? The use of pod to enter and exit code reminds me of C code that is riddled with #ifdef's ... it's very hard to grok the execution path from looking at the source. Further, compilation of one form doesn't ensure the other form is valid code. It's essentially #ifdef'd using POD!

    My suggestion ... write the test cases in Perl, and keep them seperate from your main code (in a seperate file if needed). This way, you won't be coding tests that pass your code, since you'll have to think more about your tests. Some programming courses teach "write tests first". Well, I seldom do this (bad flyingmoose!) but the concept is that, this way, you test without preconceptions.

    So in conclusion, I think this model would be A) look a lot like ifdef'd code (hard to read) and B) be full of preconceptions since your test cases would be above your code. Also, it would be yet-another-syntax to remember, and, after all, we know Perl. My vote -- keep your tests as code, just document them.

    Anyhow, just my fifty three cents. I'm open to debate on this, I just want to play devil's advocate a bit...

[reply]
      The Devil's Advocate is good - the term comes from a church official appointed to research and present arguments against a proposed sainthood to ensure that the case *for* that sainthood is as watertight as possible :-)

      I also posted this to the London Perl Mongers list, and from the feedback there, it seems that I wasn't quite as clear as I should have been. I see this as being a way to auto-generate the repetitive simple tests that I hate writing - exactly the ones that are needed for the example I gave. Any more complex method still needs all those tests to make sure that it is getting at least part of its argument sanity-checking correct. I do not propose that any such mechanism should completely obviate the need to write some tests by hand.

      Even if I use Params::Validate or Class::Contract I'd still need to write those sorts of tests, just to check that I've used those modules correctly.

      Your point about it maybe making the module harder to read is a good one, although one which can - I hope - be solved by choosing the right syntax.

[reply]

        Can you give an example of the kind of things you would want to generate? I'm not getting a clear idea of what you're expecting.

        My first reaction is that the need to generate repetitive tests would be a code smell indicating that some abstraction in the code is being missed - but that may be because I'm missing your point :-)

[reply]
      Some programming courses teach "write tests first"

      Writing tests first is an excellent practice, but often leads to an unfortunate tendency for developers to ignore further whitebox methods. Agile methods talk about writing your tests, then writing your code until you get a green bar. A green bar at this stage should *not* be taken as a pass, but only an indicator that the code now fullfills its contract. That is insufficient to pass the code. Branch and boundary coverage simply can't be analyzed until after the code is written.

[reply]
        A green bar at this stage should *not* be taken as a pass, but only an indicator that the code now fullfills its contract. That is insufficient to pass the code. Branch and boundary coverage simply can't be analyzed until after the code is written.

        While I take your point, the test-first response would be that if boundary behavior is important then it forms part of the code's contract, and so there should a test for it.

        Branch and statement coverage should come out at 100% if you've been doing TDD properly, since you shouldn't have been writing any code that wasn't motivated by a failing test.

        Not that whitebox testing and coverage tests are useless of course - but with a team doing TDD they're much more useful as pointers to where areas where TDD is being skipped or done poorly.

[reply]
        It's obvious that tests do not cease (edit: typo FIXED!) to evolve after the code is complete. However, it should be stated that (if you do have a solid API) writing tests first has some advantages. Namely, you can make sure you implemented your entire API and that API works.

        Once you start scrolling through hundreds of lines of code, it's hard to visualize your API use cleanly because you start to confuse the API with the implementation. Again, I don't do this nearly enough, but it has great merits and this is something I *should* do for larger projects.

        By all means, tests should evolve while the program is written -- however boundary coverage should be one of the first kinds of things you think about when testing your API. That is what automated testing is for. If your API passes all tests, and the whole of your API is tested, you won't have any issues with coverage...harder said than done.

        Naturally, testing code by hand is critical in validing that the tests themselves are valid.

[reply]
Re: Automatic generation of tests
by tachyon (Chancellor) on Feb 28, 2004 at 11:16 UTC
[reply]

Back to Meditations