Free tests last match software for linux

Test::Class is a Perl module that allows you to easily create test classes in an xUnit/JUnit style.

SYNOPSIS

package Example::Test;
use base qw(Test::Class);
use Test::More;

# setup methods are run before every test method.
sub make_fixture : Test(setup) {
my $array = [1, 2];
shift->{test_array} = $array;
};

# a test method that runs 1 test
sub test_push : Test {
my $array = shift->{test_array};
push @$array, 3;
is_deeply($array, [1, 2, 3], push worked);
};

# a test method that runs 4 tests
sub test_pop : Test(4) {
my $array = shift->{test_array};
is(pop @$array, 2, pop = 2);
is(pop @$array, 1, pop = 1);
is_deeply($array, [], array empty);
is(pop @$array, undef, pop = undef);
};

# teardown methods are run after every test method.
sub teardown : Test(teardown) {
my $array = shift->{test_array};
diag("array = (@$array) after test(s)");
};
later in a nearby .t file
#! /usr/bin/perl
use Example::Test;

# run all the test methods in Example::Test
Test::Class->runtests;

Outputs:

1..5
ok 1 - pop = 2
ok 2 - pop = 1
ok 3 - array empty
ok 4 - pop = undef
# array = () after test(s)
ok 5 - push worked
# array = (1 2 3) after test(s)

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/

Test::Glade is a simple way to test Gtk2::GladeXML-based apps.

SYNOPSIS

use Test::Glade tests => 2;

my $glade_xml = interface.glade;
has_widget( $glade_xml, {
name => main_window,
type => GtkWindow,
properties => {
title => Test Application,
type => GTK_WINDOW_TOPLEVEL,
resizable => 1,
},
} );

has_widget( $glade_xml, {
type => GtkButton,
properties => {label => Press me!},
signals => {clicked => button_pressed_handler},
} );

GUIs are notoriously difficult to test. Historically this was well deserved as the available perl GUI toolkits did not encourage separation of the view and controller layers. The introduction of the Glade GUI designer and Gtk2::GladeXML changed that by segregating user interface and logical components (into GladeXML and Perl files respectively).

Users who avoid creating GUI elements from within their application logic can now test each layer separately with appropriate tools. The Perl logic can be verified with standard unit tests and this module provides a way to inspect and verify the GladeXML UI specification. You can confirm that a given widget exists, that it has the correct label and other attributes, that it will be correctly placed in the interface and that it will respond to signals as expected.

Test::Singleton is a test for Singleton classes.

SYNOPSIS

use Test::More tests => 1;
use Test::Singleton;
is_singleton( "Some::Class", "new", "instance" );

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

This is asimple, basic module for checking whether a class is a Singleton. A Singleton describes an object class that can have only one instance in any system. An example of a Singleton might be a print spooler or system registry, or any kind of central dispatcher.

For a description and discussion of the Singleton class, see "Design Patterns", Gamma et al, Addison-Wesley, 1995, ISBN 0-201-63361-2.

Test::TempDatabase is a Perl module for temporary database creation and destruction.

SYNOPSIS

use Test::TempDatabase;

my $td = Test::TempDatabase->create(dbname => temp_db);
my $dbh = $td->handle;

... some tests ...
# Test::TempDatabase drops database

This module automates creation and dropping of test databases.

USAGE

Create test database using Test::TempDatabase->create. Use handle to get a handle to the database. Database will be automagically dropped when Test::TempDatabase instance goes out of scope.

$class->become_postgres_user

When running as root, this function becomes different user. It decides on the user name by probing TEST_TEMP_DB_USER, SUDO_USER environment variables. If these variables are empty, default "postgres" user is used.
create

Creates temporary database. It will be dropped when the resulting instance will go out of scope.

Arguments are passed in as a keyword-value pairs. Available keywords are:
dbname: the name of the temporary database.

rest: the rest of the database connection string. It can be used to connect to a different host, etc.

username, password: self-explanatory.

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.