in reply to Re: What is the largest number of tests you have created for a single project you have worked on?
in thread What is the largest number of tests you have created for a single project you have worked on?
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:
Test 1: print the program's Help menu: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'); ...
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()'.