in reply to How to get started in test first programming without writing modules? package ?

Do the developement in a perl module and write a pl file to execute the code after testing. That means 3 files; .t, .pm, and .pl where the Ruby guys only needed 2.
The 3+ file option is best in Perl IMHO. Who cares if you have three files or only two? Actually, it is often best to have more than three files. That is, to write a number of .t files for each .pm file. Why? Because maintaining a number of (small) .t files, one to test each aspect of a module, is usually easier to manage and maintain than a single (monolithic) .t file. I favour this general approach in any language, including Ruby.

When writing Perl scripts, I typically abstract the work they do into CPAN-like modules and unit test each module using Test::More and the prove command. I strive to keep my script mainlines as short as is practicable. There are many examples of this approach on the CPAN; see, for example, the perltidy command, part of the Perl::Tidy distribution and the perlcritic command, part of the Perl::Critic distribution.

At work I would like to create my own modules but I was told to have everything in one file for the application I've been working on.
Why? That looks like very poor advice to me.

  • Comment on Re: How to get started in test first programming without writing modules? package ?

Replies are listed 'Best First'.
Re^2: How to get started in test first programming without writing modules? package ?
by Gulliver (Monk) on May 16, 2011 at 02:05 UTC
    Why? That looks like very poor advice to me.

    I couldn't agree with you more. I was told to keep things simple by the same guy who made a few suggestions in a meeting that ballooned the project from 50 lines to 500. Not that I minded putting in interesting extra features, but I don't like being constrained.

    I just realized that testing gives me good justification to put all the functions into a module. I would say modules but I won't push my luck.