Free test functions software for linux

Bio::NEXUS::Functions is a Perl module that provides private utility functions for the module.

This package provides private functions that are not object-specific.

Test soon project is a testing framework trying to enable you to write tests quickly, organize them easily and still being flexible.

The goal is to utilize the strengths of C++ while minimizing the impact of its weaknesses.

Test::MultiFork is a test suite that has support for multi-process programs.

SYNOPSIS

use Test::MultiFork;

($name, $letter, $number) = procname([new name])
lockcommon()
@oldvalues = getcommon()
setcommon(@newvalues)
unlockcommon()

use Test::MultiFork qw(groupwait setgroup dofork stderr bail_on_bad_plan)

groupwait([$tag])
$oldgroup = setgroup([$newgroup])
dofork(fork_specification)

This test module is to support creating test suites for programs and modules that run as multiple processes and do mostly blocking I/O.

Test::MultiFork handles the forking so that it can set up each child to coordinate the output. The output from each child fork is redirected to the parent. Each fork produces normal test output -- possibly using normal test modules like Test::Simple. The output is collected and rewritten by the parent process.

Each child fork has a letter and number designation. The forks are created by dofork(). Dofork takes a specifiction on the form: ([a-z](d*))+. That is to say, one or more lower-case letters, each optionally followd by a number. The number says how many children to fork for that letter (default one). The specifier ab2c3 means have one a child (numbered 1); two b children (numbered 1, 2); and three c children (numbered 1, 2, 3).

To aid in writing tests, Test::MultiFork will pass data between the child processes. The data is test-writer defined.

Test::Chunks is a Data Driven Testing Framework.

NOTE - This module has been deprecated and replaced by Test::Base. This is basically just a renaming of the module. Test::Chunks was not the best name for this module. Please discontinue using Test::Chunks and switch to Test::Base.
Helpful Hint: change all occurences of chunk to block in your test code, and everything should work exactly the same.

SYNOPSIS

use Test::Chunks;
use Pod::Simple;

delimiters qw(=== +++);
plan tests => 1 * chunks;

for my $chunk (chunks) {
# Note that this code is conceptual only. Pod::Simple is not so
# simple as to provide a simple pod_to_html function.
is(
Pod::Simple::pod_to_html($chunk->pod),
$chunk->text,
$chunk->name,
);
}

__END__

=== Header 1 Test

This is an optional description
of this particular test.

+++ pod
=head1 The Main Event
+++ html
< h1 >The Main Event< /h1 >


=== List Test
+++ pod
=over
=item * one
=item * two
=back

+++ html
< ul >
< li >one< /li >
< li >two< /li >
< /ul >

There are many testing situations where you have a set of inputs and a set of expected outputs and you want to make sure your process turns each input chunk into the corresponding output chunk. Test::Chunks allows you do this with a minimal amount of code.

Test::Version is a Perl module that has the role to check for VERSION information in modules.

SYNOPSIS

use Test::Version;
plan tests => $num_tests;
version_ok( $file );

FUNCTIONS

version_ok( FILENAME, [EXPECTED, [NAME] ] )
version_ok requires a filename and returns one of the three values:

NO_FILE Could not find the file
NO_VERSION File had no VERSION information
VERSION_OK VERSION information exists

version_ok okays a test without an expected result if it finds VERSION information, or if an expected result is specified and it finds that condition. For instance, if you know there is no VERSION information,

version_ok( $file, NO_VERSION );

When it fails, version_ok will show error information.

The optional third argument NAME is the name of the test which version_ok passes through to Test::Builder. Otherwise, it choose a default test name "VERSION test for FILENAME".

Test::Dependencies is a Perl module to ensure that your Makefile.PL specifies all module dependencies.

SYNOPSIS

In your t/00-dependencies.t:
use Test::Dependencies exclude =>
[qw/ Your::Namespace Some::Other::Namespace /];

ok_dependencies();

Makes sure that all of the modules that are used are listed in the Makefile.PL as dependencies.

EXPORTED FUNCTIONS

ok_dependencies

This should be the only test called in the test file. It scans bin/ and lib/ for module usage and t/ for build usage. It will then test that all modules used are listed as required in Makefile.PL, all modules used in t/ are listed as build required, that all modules listed are actually used, and that modules that are listed are not in the core list.

Test::Manifest is a Perl module created to interact with a t/test_manifest file.

SYNOPSIS

# in Makefile.PL
eval "use Test::Manifest";

# in the file t/test_manifest, list the tests you want
# to run

Test::Harness assumes that you want to run all of the .t files in the t/ directory in ascii-betical order during make test unless you say otherwise. This leads to some interesting naming schemes for test files to get them in the desired order. This interesting names ossify when they get into source control, and get even more interesting as more tests show up.

Test::Manifest overrides the default behaviour by replacing the test_via_harness target in the Makefile. Instead of running at the t/*.t files in ascii-betical order, it looks in the t/test_manifest file to find out which tests you want to run and the order in which you want to run them. It constructs the right value for MakeMaker to do the right thing.

In t/test_manifest, simply list the tests that you want to run. Their order in the file is the order in which they run. You can comment lines with a #, just like in Perl, and Test::Manifest will strip leading and trailing whitespace from each line. It also checks that the specified file is actually in the t/ directory. If the file does not exist, it does not put its name in the list of test files to run.

Optionally, you can add a number after the test name in test_manifest to define sets of tests. See get_t_files() for more information.

Functions

run_t_manifest( TEST_VERBOSE, INST_LIB, INST_ARCHLIB, TEST_LEVEL )

Run all of the files in t/test_manifest through Test::Harness:runtests in the order they appear in the file.

eval "use Test::Manifest";
get_t_files( [LEVEL] )

In scalar context it returns a single string that you can use directly in WriteMakefile(). In list context it returns a list of the files it found in t/test_manifest.

If a t/test_manifest file does not exist, get_t_files() returns nothing.
get_t_files() warns you if it cant find t/test_manifest, or if entries start with "t/". It skips blank lines, and strips Perl style comments from the file.

Each line in t/test_manifest can have three parts: the test name, the test level (a floating point number), and a comment. By default, the test level is 1.

test_name.t 2 #Run this only for level 2 testing

Without an argument, get_t_files() returns all the test files it finds. With an argument that is true (so you cant use 0 as a level) and is a number, it skips tests with a level greater than that argument. You can then define sets of tests and choose a set to run. For instance, you might create a set for end users, but also add on a set for deeper testing for developers.

Experimentally, you can include a command to grab test names from another file. The command starts with a ; to distinguish it from a true filename. The filename (currently) is relative to the current working directory, unlike the filenames, which are relative to t/. The filenames in the included are still relative to t/.

;include t/file_with_other_test_names.txt

To select sets of tests, specify the level in the variable TEST_LEVEL during `make test`.

make test # run all tests no matter the level
make test TEST_LEVEL=2 # run all tests level 2 and below

make_test_manifest()

Creates the test_manifest file in the t directory by reading the contents of the t directory.

TO DO: specify tests in argument lists.

TO DO: specify files to skip.

manifest_name()

Returns the name of the test manifest file, relative to t/