in reply to How do you structure and run module test code?

I suggest finding a (simple) CPAN module you like and examining the tests in its distribution.

The way to figure out what tests to write:

  1. Decide what you want a function to do.
  2. Write the documentation that says "foo() does this when given that"
  3. Write tests in a test file (I would name it descriptively like "t/functions/001-foo.t") that prove that "foo()" does what the doc says. They will fail.
  4. Write the code that makes the tests pass.

Running tests inside an editor session seems silly to me (but a lot of what TheDamian does and advocates is both way too dogmatic and way too clever for a simple monk like me). I run my tests in a separate shell session, and while they are running I am doing something else useful with the editor or in another shell.

One thing I strongly suggest is to make your test files not only thematic, but small and simple. Some test files will consist almost completely of test statements ("ok(), is_deeply()" etc) ... in which case it's fine to have lots of tests therein. You might create tests in a loop as well. But once you need even a few lines of code to provide data for the test or make the test run, I think it's much better to have one test per file, since you will probably turn on verbosity as soon as you are working with that test, and the output of all the others will be too noisy.

Hope this helps!


The way forward always starts with a minimal test.
  • Comment on Re: How do you structure and run module test code?