Re: test files - organising

First things first: prove -r or prove -- recurse will chug through the directories looking for *.t files to run.

Second things second: what do you feel comfortable with? Do things you are comfortable with. There is, after all, More Than One Way....

I tend to use the format "tnn-short-memory-jogging-phrase.t", to name my test-files. (ie: t00-basic-api.t, t05-extended-api.t, etc) Each file consists of all of the tests for a single module. I select 'nn' to have common functions grouped together in the prove() output or a directory listing. This works for me until the test-file for a single module gets 'too large', either logically (more that three or four logical/functional groupings) or physically (20+ one-line tests). (I basically follow the same principal that I use in deciding whether some code needs to be broken up into sub-routines -- Do I have to scroll up and down more than half-a-screen? Split it up!) When a test file gets too large, then I build the sub-directory for the module, move the test-harness into it, and refactor into several (much smaller) tnn-aaa.t files.

This has worked reasonably well for me over the years, but it's really a matter of personal taste. Just set things up so that it is easy for you to keep track of things during the Development process.

Also, remember that the Maintenance Programmer has to be able to pick up your test-file philosophy with out too much difficulty later. Make it easy for Them, and They are much more likely to Bless Your Name when they have to fix bugs and make functional changes.

----
I Go Back to Sleep, Now.

OGB

Comment on Re: test files - organising Select or Download Code

Replies are listed 'Best First'.
Re^2: test files - organising by doom (Deacon) on Feb 14, 2008 at 23:27 UTC
I have to say that "whatever you feel comfortable with" isn't really an adequate answer to this kind of question: yeah there's lots of ways that things can be done, but some are more common that others, and other things being equal, it's going to be better to go with "standard practice" rather than making up a new way of doing things. That said, Old_Gray_Bear's version of "standard practice" doesn't sound bad, and might not be a lot different from what I do, which is: Scatter "t" subdirectories throughout the code tree, with tests located near the code that they test. So the tests for Modular/Stuff.pm are in Modular/t. When first writing tests for Modular::Stuff, I name the test file Modular-Stuff.t. As the tests get more elaborate, I move the tests into numbered files (e.g. 00-init-Modular-Stuff.t, 01-db_access-Modular-Stuff.t, 02-data_munging-Modular-Stuff.t...). I put data files that tests use in a sub-directory of t called "dat", and I sometimes put shared code for these tests in modules located in a sub-directory called "lib". And yes, `prove -r` is indeed the way to run it recursively. It really is a good ideas to get familar with prove, starting with the man page. One of the nice things about "prove" by the way, is that you can narrow down the tests that you run with it by doing things like: `prove '0.t' '1.t'` [download] Lately I've been playing around with reserving blocks of numbers for tests-under-development that aren't expected to work yet. Tests named '0.t' or '1.t' had better work, or something has come unstuck, but a failure in tests named '2.t' of '3.t' just means you haven't finished something yet.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: test files - organising
by doom (Deacon) on Feb 14, 2008 at 23:27 UTC

That said, Old_Gray_Bear's version of "standard practice" doesn't sound bad, and might not be a lot different from what I do, which is:

Scatter "t" subdirectories throughout the code tree, with tests located near the code that they test. So the tests for Modular/Stuff.pm are in Modular/t.
When first writing tests for Modular::Stuff, I name the test file Modular-Stuff.t. As the tests get more elaborate, I move the tests into numbered files (e.g. 00-init-Modular-Stuff.t, 01-db_access-Modular-Stuff.t, 02-data_munging-Modular-Stuff.t...).
I put data files that tests use in a sub-directory of t called "dat", and I sometimes put shared code for these tests in modules located in a sub-directory called "lib".

And yes, prove -r is indeed the way to run it recursively. It really is a good ideas to get familar with prove, starting with the man page.

One of the nice things about "prove" by the way, is that you can narrow down the tests that you run with it by doing things like:

  prove '0*.t' '1*.t'
[download]

[reply]
[d/l]
[select]