Free tested software for linux

Test::Cmd is a Perl module for portable testing of commands and scripts.

SYNOPSIS

use Test::Cmd;

$test = Test::Cmd->new(prog => program_or_script_to_test,
interpreter => script_interpreter,
string => identifier_string,
workdir => ,
subdir => dir,
match_sub => $code_ref,
verbose => 1);

$test->verbose(1);

$test->prog(program_or_script_to_test);

$test->basename(@suffixlist);

$test->interpreter(script_interpreter);

$test->string(identifier string);

$test->workdir(prefix);

$test->workpath(subdir, file);

$test->subdir(subdir, ...);
$test->subdir([sub, dir], ...);

$test->write(file, read($contents, [subdir, file]);
$test->read(@lines, [subdir, file]);

$test->writable(dir);
$test->writable(dir, $rwflag);
$test->writable(dir, $rwflag, %errors);

$test->preserve(condition, ...);

$test->cleanup(condition);

$test->run(prog => program_or_script_to_test,
interpreter => script_interpreter,
chdir => dir, args => arguments, stdin => pass(condition, &func);

$test->fail(condition);
$test->fail(condition, &func);
$test->fail(condition, &func, $caller);

$test->no_result(condition);
$test->no_result(condition, &func);
$test->no_result(condition, &func, $caller);

$test->stdout;
$test->stdout($run_number);

$test->stderr;
$test->stderr($run_number);

$test->match(@lines, @matches);
$test->match($lines, $matches);

$test->match_exact(@lines, @matches);
$test->match_exact($lines, $matches);

$test->match_regex(@lines, @regexes);
$test->match_regex($lines, $regexes);

$test->diff_exact(@lines, @matches, @output);
$test->diff_exact($lines, $matches, @output);

$test->diff_regex(@lines, @regexes, @output);
$test->diff_regex($lines, $regexes, @output);

sub func {
my ($self, $lines, $matches) = @_;
# code to match $lines and $matches
}
$test->match_sub(&func);
$test->match_sub(sub { code to match $_[1] and $_[2] });

$test->here;

The Test::Cmd module provides a low-level framework for portable automated testing of executable commands and scripts (in any language, not just Perl), especially commands and scripts that interact with the file system.

The Test::Cmd module makes no assumptions about what constitutes a successful or failed test. Attempting to read a file that doesnt exist, for example, may or may not be an error, depending on the software being tested.

Consequently, no Test::Cmd methods (including the new() method) exit, die or throw any other sorts of exceptions (but they all do return useful error indications). Exceptions or other error status should be handled by a higher layer: a subclass of Test::Cmd, or another testing framework such as the Test or Test::Simple Perl modules, or by the test itself.
(That said, see the Test::Cmd::Common module if you want a similar module that provides exception handling, either to use directly in your own tests, or as an example of how to use Test::Cmd.)

In addition to running tests and evaluating conditions, the Test::Cmd module manages and cleans up one or more temporary workspace directories, and provides methods for creating files and directories in those workspace directories from in-line data (that is, here-documents), allowing tests to be completely self-contained. When used in conjunction with another testing framework, the Test::Cmd module can function as a fixture (common startup code for multiple tests) for simple management of command execution and temporary workspaces.

The Test::Cmd module inherits File::Spec methods (file_name_is_absolute(), catfile(), etc.) to support writing tests portably across a variety of operating and file systems.

A Test::Cmd environment object is created via the usual invocation:

$test = Test::Cmd->new();

Arguments to the Test::Cmd::new method are keyword-value pairs that may be used to initialize the object, typically by invoking the same-named method as the keyword.

Test::Data is a Perl module to test functions for particular variable types.

SYNOPSIS

use Test::Data qw(Scalar Array Hash Function);

Test::Data provides utility functions to check properties and values of data and variables.

Functions

Plug-in modules define functions for each data type. See the appropriate module.

How it works

The Test::Data module simply emports functions from Test::Data::* modules. Each module defines a self-contained function, and puts that function name into @EXPORT. Test::Data defines its own import function, but that does not matter to the plug-in modules.

If you want to write a plug-in module, follow the example of one that already exists. Name the module Test::Data::Foo, where you replace Foo with the right name. Test::Data should automatically find it.

Test::More is yet another framework for writing test scripts.

SYNOPSIS

use Test::More tests => 23;
# or
use Test::More qw(no_plan);
# or
use Test::More skip_all => $reason;

BEGIN { use_ok( Some::Module ); }
require_ok( Some::Module );

# Various ways to say "ok"
ok($got eq $expected, $test_name);

is ($got, $exptected, $test_name);
isnt($got, $expected, $test_name);

# Rather than print STDERR "# heres what went wrongn"
diag("heres what went wrong");

like ($got, qr/expected/, $test_name);
unlike($got, qr/expected/, $test_name);

cmp_ok($got, ==, $expected, $test_name);

is_deeply($got_complex_structure, $expected_complex_structure, $test_name);

SKIP: {
skip $why, $how_many unless $have_some_feature;

ok( foo(), $test_name );
is( foo(42), 23, $test_name );
};

TODO: {
local $TODO = $why;

ok( foo(), $test_name );
is( foo(42), 23, $test_name );
};

can_ok($module, @methods);
isa_ok($object, $class);

pass($test_name);
fail($test_name);

BAIL_OUT($why);

# UNIMPLEMENTED!!!
my @status = Test::More::status;

STOP! If youre just getting started writing tests, have a look at Test::Simple first. This is a drop in replacement for Test::Simple which you can switch to once you get the hang of basic testing.

The purpose of this module is to provide a wide range of testing utilities. Various ways to say "ok" with better diagnostics, facilities to skip tests, test future features and compare complicated data structures. While you can do almost anything with a simple ok() function, it doesnt provide good diagnostic output.

Test::Resub is a lexically scoped subroutine replacement for testing.

SYNOPSIS

#!/usr/bin/perl

use Test::More tests => 4;
use Test::Resub qw(resub);

{
package Somewhere;
sub show {
my ($class, $message) = @_;
return "$class, $message";
}
}

# sanity
is( Somewhere->show(beyond the sea), Somewhere, beyond the sea );

# scoped replacement of subroutine with argument capturing
{
my $rs = resub Somewhere::show, sub { hi }, capture => 1;
is( Somewhere->show(over the rainbow), hi );
is_deeply( $rs->method_args, [[over the rainbow]] );
}

# scope ends, resub goes away, original code returns
is( Somewhere->show(waiting for me), Somewhere, waiting for me );

This module allows you to temporarily replace a subroutine/method with arbitrary code. Later, you can tell how many times was it called and with what arguments each time. You can also specify that the subroutine/method must get called, must not get called, or may be optionally called.

Test::Deep is a Perl module for extremely flexible deep comparison.

SYNOPSIS

use Test::More tests => $Num_Tests;
use Test::Deep;

cmp_deeply(
$actual_horrible_nested_data_structure,
$expected_horrible_nested_data_structure,
"got the right horrible nested data structure"
);

cmp_deeply(
$object,
methods(name => "John", phone => "55378008"),
"object methods ok"
);

cmp_deeply(
@array,
[$hash1, $hash2, ignore(
"first 2 elements are as expected, ignoring 3"
);

cmp_deeply(
$object,
noclass({value => 5}),
"object looks ok, not checking its class"
);

cmp_deeply(
@result,
bag(a, b, {key => [1, 2]}),
"array has the 3 things we wanted in some order"
);

If you dont know anything about automated testing in Perl then you should probably read about Test::Simple and Test::More before preceding. Test::Deep uses the Test::Builder framework.

Test::Deep gives you very flexible ways to check that the result you got is the result you were expecting. At its simplest it compares two structures by going through each level, ensuring that the values match, that arrays and hashes have the same elements and that references are blessed into the correct class. It also handles circular data structures without getting caught in an infinite loop.
Where it becomes more interesting is in allowing you to do something besides simple exact comparisons. With strings, the eq operator checks that 2 strings are exactly equal but sometimes thats not what you want. When you dont know exactly what the string should be but you do know some things about how it should look, eq is no good and you must use pattern matching instead. Test::Deep provides pattern matching for complex data structures.

Test::Simple is a Perl module with basic utilities for writing tests.

SYNOPSIS

use Test::Simple tests => 1;

ok( $foo eq $bar, foo is bar );

** If you are unfamiliar with testing read Test::Tutorial first! **

This is an extremely simple, extremely basic module for writing tests suitable for CPAN modules and other pursuits. If you wish to do more complicated testing, use the Test::More module (a drop-in replacement for this one).
The basic unit of Perl testing is the ok. For each thing you want to test your program will print out an "ok" or "not ok" to indicate pass or fail. You do this with the ok() function (see below).

The only other constraint is you must pre-declare how many tests you plan to run. This is in case something goes horribly wrong during the test and your test program aborts, or skips a test or whatever. You do this like so:

use Test::Simple tests => 23;

You must have a plan.

ok
ok( $foo eq $bar, $name );
ok( $foo eq $bar );

ok() is given an expression (in this case $foo eq $bar). If its true, the test passed. If its false, it didnt. Thats about it.

ok() prints out either "ok" or "not ok" along with a test number (it keeps track of that for you).

# This produces "ok 1 - Hell not yet frozen over" (or not ok)
ok( get_temperature($hell) > 0, Hell not yet frozen over );

If you provide a $name, that will be printed along with the "ok/not ok" to make it easier to find your test when if fails (just search for the name). It also makes it easier for the next guy to understand what your test is for. Its highly recommended you use test names.

All tests are run in scalar context. So this:

ok( @stuff, I have some stuff );
will do what you mean (fail if stuff is empty)

Test::Simple will start by printing number of tests run in the form "1..M" (so "1..5" means youre going to run 5 tests). This strange format lets Test::Harness know how many tests you plan on running in case something goes horribly wrong.
If all your tests passed, Test::Simple will exit with zero (which is normal). If anything failed it will exit with how many failed. If you run less (or more) tests than you planned, the missing (or extras) will be considered failures. If no tests were ever run Test::Simple will throw a warning and exit with 255. If the test died, even after having successfully completed all its tests, it will still be considered a failure and will exit with 255.

So the exit codes are...
0 all tests successful
255 test died or all passed but wrong # of tests run
any other number how many failed (including missing or extras)

If you fail more than 254 tests, it will be reported as 254.

This module is by no means trying to be a complete testing system. Its just to get you started. Once youre off the ground its recommended you look at Test::More.

Otk Tests are tests for the Open Tool Kit project.
Otk is a portable widget library for making graphical user interfaces for C programs. It emphasizes simplicity for the application programmer without eliminating capability. Based on OpenGL, Otk supports Linux, Unix, and other OSs neutrally and efficiently. It is simple and compact, and it strives for easy compilation and linking to other applications.
In seeking to address several issues associated with earlier graphics APIs, Otk explores some interesting methods, such as window-relative layout instead of pixel-based layout.
Enhancements:
- This package of Otk test programs includes scripts to automatically compile and invoke them sequentially.
- The scripts enable quickly testing OTK_LIB functionality.
- The package will be handy for continued regression testing whenever otk_lib is changed or updated.
- It checks that OTK and applications compile will on various platforms, and exercises most features to test for proper operations.

Test::MockDBI is Perl module mock DBI interface for testing.

SYNOPSIS

use Test::MockDBI;
OR
use Test::MockDBI qw( :all );

Test::MockDBI::set_dbi_test_type(42);
if (Test::MockDBI::get_dbi_test_type() == 42) {
...

$mock_dbi = get_instance Test::MockDBI;

$mock_dbi->bad_method(
$method_name,
$dbi_testing_type,
$matching_sql);

$mock_dbi->bad_param(
$dbi_testing_type,
$param_number,
$param_value);

$mock_dbi->set_retval_array(
$dbi_testing_type,
$matching_sql,
@retval || CODEREF);
$mock_dbi->set_retval_array(MOCKDBI_WILDCARD, ...

$mock_dbi->set_retval_scalar(
$dbi_testing_type,
$matching_sql,
$retval || CODEREF);
$mock_dbi->set_retval_scalar(MOCKDBI_WILDCARD, ...

$mock_dbi->set_rows(
$dbi_testing_type,
$matching_sql,
$rows || CODEREF);
$mock_dbi->set_rows(MOCKDBI_WILDCARD, ...

Test::MockDBI provides a way to test DBI interfaces by creating rules for changing the DBIs behavior, then examining the standard output for matching patterns.

Testing using Test::MockDBI is enabled by setting the DBI testing type to a non-zero value. This can be done either by using a first program argument of "--dbitest[=TYPE]", or by using the class method Test::MockDBI::set_dbi_test_type(). (Supplying a first argument of "--dbitest[=TYPE]" often works well during testing.) TYPE is a simple integer (/^d+$/). Supplying "--dbitest[=TYPE]" as a first argument works even if no other command-line processing is done, as Test::MockDBI does its own command-line processing to check for this first "--dbitest[=TYPE]" argument.

You will want to add "--dbitest[=TYPE]" during a BEGIN block before the "use Test::MockDBI", so that the mock DBI is initialized as early as possible.

TYPE is optional, as a first argument of "--dbitest" will set the DBI testing type to 1 (one). DBI testing is also disabled by "--dbitest=0" (although this may not be generally useful). The class method Test::MockDBI::set_dbi_test_type() can also be used to set or change the DBI testing type.