Here's one way to get started quickly with testing, in about 10 lines of code.
I recently wrote my first tests to drive a Java CLI app, and the investment was repaid quickly when they were easily ported to a second project w/ a similar CLI.
I spent less time manually testing, and was more confident about changing the code because I could quickly test it.
The program has a simple
command-line menu of about 10 items. I tested the program manually using that menu, which became tedious during development. So I looked at the excellent book:
Perl Testing, A Developer's Notebook
(ISBN 9780596100926).
The section on Testing Interactive Programs in chapter 9 worked for me.
(I had previously read the book and written a few tests.
If you are new to testing, start at the beginning instead of the end, if necessary).
The man pages for the test modules are also helpful.
I needed Test::Expect for this solution.
That required me to make a unique and consistent prompt string in the programs under test, which was a good thing.
My first test looked like this:
use strict;
use warnings;
use Test::More tests => 3;
use Test::Expect;
expect_run(
command => "java -cp '.' src/TestRoster",
prompt => " >: ",
quit => "0\n",
);
expect_send( '97', 'Ask for help');
expect_like( qr/-Help about the menu items.+Terminate.+/sm, '... show
+s help text');
...
Test 1: print the program's Help menu:
Initialize with expect_run():
the command to run the program under test;
the expected prompt;
and how to terminate it.
Send the request from the test program (97); see the response at the console
(the program's help text);
write a regex in the test program to match the response
(qr/.../).
You now have a test.
Run that Perl test program individually; or use 'prove' to run one or more tests, and to show a summary of the output.
Write a test before you write the code for the next action.
Run it, see it fail; write the code; run the test; repeat until no failures.
You are now doing test-driven development.
Thanks for the tip on
'done_testing()'.
|