When it comes to modules, there are well established techniques for writing tests. With a standard CPAN module, there are test scripts provided - either a single script test.pl, or a directory of scripts, t/*.t.

In most cases, the tests operate on one or more .pm modules, exercising their functions, method calls, etc. testing out the scenarios. Sometimes a CPAN module delivers one or more "exe_files", which are scripts. Examples of this are dbish and lwp_rget. I also count sub shell inside CPAN.pm and CPANPLUS.pm as a script: it's just a script that is wrapped up inside the .pm module itself.

Some people may argue that scripts that accompany modules do not require tests as they contain no functionality - merely calls to the .pm module code. I disagree.

As far as I can see, these scripts are delivered with little or no collateral by way of accompanying documenation and tests (though there are probably exceptions to this). As far as I am concerned, the "exe_files" are deliverables which also need tests to verify that they are working correctly. The nature of the script in question, and its tests, could be one of the following:

• Command shell scripts. These take lines of input from stdin, and display results on stdout and stderr. I envisage the tests as using IPC::Open3 to fork a process to run the script, passing commands and checking returned text against expected results. The tests can also be examining external information, such as the file system or a database.

• Daemon scripts. Besides considerations that the daemon needs to be isolated from any "live" instance of the daemon alteady running, the tests need to handle and check for start up and shut down of the daemon, together with passing messages to and from the daemon.

• Batch scripts. These are probably the simplest, as it may be merely a matter of running them under system or backticks and checking expected results.

• GUI scripts. These must be the hardest to test. For example, Tk provides access to the bindings, to allow automation of mouse and keyboard events. But it's still very difficult to automate.

• Web scripts. I include CGI and mod_perl scripts here, along with client side LWP and IRC chatbots. What would be really nice is something that could fake a webserver, and generate the HTTP requests that the likes of CGI.pm is expecting.

As is apparent, I don't think that there is a single one-size-fits-all test harness for scripts, but I am interested in whether any modules exist which cover the framework of testing each of the types of script above. I'm also keen on keeping the tests portable, hence not relying on operating system dependent IPC mechanisms.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.