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

[Gulliver]

I recently went to a cleancoders event where we were using Ruby to solve Katas with test first programming. I was itching to try it in Perl but I have never done testing in Perl or written modules. I have been reading 'Advanced Perl Programming' and 'Testing Perl' but they seem to be aimed at testing perl modules.

My options seem to be:

--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.

--Mix tests into my application and use a variable or command line argument to enable the tests.

Are there other options?

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. I'm thinking it should be possible to put my functions into a package in the same file and then run the tests against that package.

[roboticus]

Gulliver:

You don't really need to split it into 3 files. Once I encountered the modulino concept, I've been playing around with modules having their own test fixtures inside them. So if you call the module directly, it will test itself. So you'd need only the module (.pm) for the code and tests, and you can just use a .pl file to use your module for other things.

If you wanted the application, module and tests all in a single file, you can do that, too. For that, I'd put it into test mode with a command-line switch or something, though.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[Gulliver]

Thanks for the link to modulinos in the book 'Mastering Perl'. It looks like a really good book and this was just was I was looking for. After reading about it I realized I need to work through the basics of modules and testing modules as described in the book 'Testing Perl'.

Using the example in the first chapter of Testing Perl I was able to make a simple module with a few functions and a test file. It turned out to be simpler to set up than Ruby was.

[moritz]

Suppose you want to write and test a function that adds number, you could do it like this:

use strict;
use warnings;

sub add { $_[0] + $_[1] };

if (defined $ARGV[0] && $ARGV[0] eq 'test') {
    use Test::More;
    plan tests => 1;
    is add(1, 2), 3, 'Can add two numbers';
} else {
    print add(@ARGV), "\n";
}

And run it as

$ perl foo.pl test
1..1
ok 1 - Can add two numbers
$ perl foo.pl 4 6
10

Ok, the example is really lame, but it shows how you can approach the whole thing.

[eyepopslikeamosquito]

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.

[Gulliver]

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.

[choroba]

Reminds me this node: String Calculator TDD Kata done in Perl

[MidLifeXis]

Test::Inline is a method I have used in the past. I am not convinced that it is the "one true way", but it provides another tool in the toolbox. It does allow you to keep the tests near to the section being tested, but without a folding editor, it can get ugly.

Update: I should have emphasized in the past more. I don't use this on new projects, although I do use the STDOUT / STDERR capture code it uses.

[tye]

but without a folding editor, it can get ugly

I'm curious... Do you have a folding printer? A folding 'grep'? Folding revision control diff/log/pickaxe tools? A folding merge tool? Do you never do anything with code other than "edit" it?

Even the old argument of "nobody updates the documentation unless it is within a few lines of the code that it documents" doesn't make sense for tests... unless you rarely run your tests.

I think I'll stick with keeping my test code in a separate directory tree and running the tests at least before any release / deploy. I like to be able to pickaxe for any changes to calls to the fooBiff() method either excluding test code, or including test code, or only in test code. I like being able to tell that nobody touched the Foo::Biff implementation in this release. I like to be able to see how much work is being spent on fixing unit tests, especially when the immediate implementation wasn't touched.

Do you just hardly ever do such things? Or do you not find having your test code jumbled around with your implementation code makes such things much harder? Or do you find it harder but find the juxtaposition of test and code outweighs such hurdles?

I think somebody should write a "merging" editor feature so you can keep your different types of text in separate files for all of your tools that aren't your editor and then teach your editor how to shuffle the appropriate parts of the disparate files together on the screen when editing. :)

[MidLifeXis]

I cannot say that I disagree with any of your comments, as I have been moving away from this tool (on revision) when I touch parts of my codebase.

Chalk it up to lack of experience in development (looks like 6ish years ago) and interaction with other tools. I used this solution when the "approved" rev control method in my environment was file based (sccs - not my choice), and not project based (now, git - my choice). At that time, my goal was to be able to link the revision of the test with the revision of the file it was testing. It did the job at the time. Since I switched to git, I don't find Test::Inline "necessary" anymore.

I still, however, use a folding editor. Being able to demote things unessential to the task at hand is useful to me.

Does a fanfold printer count as a folding printer? ;-b