Free tests death software for linux

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::Signature is a Perl module to automate SIGNATURE testing.

SYNOPSIS

# This is actually the t/00signature.t
# file from this distribution.
use Test::More tests => 1;
use Test::Signature;

signature_ok();

ABSTRACT

Test::Signature verifies that the Module::Signature generated signature of a module is correct.

Module::Signature allows you to verify that a distribution has not been tampered with. Test::Signature lets that be tested as part of the distributions test suite.
By default, if Module::Signature is not installed then it will just say so and not fail the test. That can be overridden though.

IMPORTANT: This is not a substitute for the users verifying the distribution themselves. By the time this module is run, the users will have already run your Makefile.PL or Build.PL scripts which could have been compromised.
This module is more for ensuring youve updated your signature appropriately before distributing, and for preventing accidental errors during transmission or packaging.

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::XML::XPath is a Perl module to test XPath assertions.

SYNOPSIS

use Test::XML::XPath tests => 3;
like_xpath( , /foo ); # PASS
like_xpath( , /bar ); # FAIL
unlike_xpath( , /bar ); # PASS

is_xpath( bar , /foo, bar ); # PASS
is_xpath( bar , /bar, foo ); # FAIL

# More interesting examples of xpath assertions.
my $xml = pub ;

# Do testing for attributes.
like_xpath( $xml, /foo[@attrib="1"] ); # PASS
# Find an element anywhere in the document.
like_xpath( $xml, //bosh ); # PASS
# Both.
like_xpath( $xml, //bosh[@args="42"] ); # PASS

This module allows you to assert statements about your XML in the form of XPath statements. You can say that a piece of XML must contain certain tags, with so-and-so attributes, etc. It will try to use any installed XPath module that it knows about. Currently, this means XML::LibXML and XML::XPath, in that order.

NB: Normally in XPath processing, the statement occurs from a context node. In the case of like_xpath(), the context node will always be the root node. In practice, this means that these two statements are identical:

# Absolute path.
like_xpath( , /foo );
# Path relative to root.
like_xpath( , foo );

Its probably best to use absolute paths everywhere in order to keep things simple.
NB: Beware of specifying attributes. Because they use an @-sign, perl will complain about trying to interpolate arrays if you dont escape them or use single quotes.

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.

Test::Extreme is a perlish unit testing framework.

SYNOPSIS

# In ModuleOne.pm combine unit tests with code

package ModuleOne;
use Test::Extreme;
sub foo { return 23 };
sub test_foo { assert_equals foo, 23 }

# at the end of the module

run_tests ModuleOne if $0 =~ /ModuleOne.pm$/;

# To run the tests in this module on the command line type

perl ModuleOne.pm

# If you have tests in several modules (say in ModuleOne.pm,
# ModuleTwo.pm and ModuleThree.pm, create test.pl containing
# precisely the following:

use ModuleOne;
use ModuleTwo;
use ModuleThree;

run_tests ModuleOne, ModuleTwo, ModuleThree,

# Then run these tests on the command line with

perl test.pl

# If you prefer to get Perls classic "ok/not ok" output use
# replace run_tests with run_tests_as_script in all of the
# above

# Also take a look at Test/Extreme.pm which includes its own
# unit tests for how to instrument a module with unit tests

Test::Extreme is a perlish port of the xUnit testing
framework. It is in the spirit of JUnit, the unit testing
framework for Java, by Kent Beck and Erich Gamma. Instead of
porting the implementation of JUnit we have ported its spirit
to Perl.

The target market for this module is perlish people
everywhere who value laziness above all else.

Test::Extreme is especially written so that it can be easily
and concisely used from Perl programs without turning them
into Java and without inducing object-oriented nightmares in
innocent Perl programmers. It has a shallow learning curve.
The goal is to adopt the unit testing idea minus the OO
cruft, and to make the world a better place by promoting the
virtues of laziness, impatience and hubris.

You test a given unit (a script, a module, whatever) by using
Test::Extreme, which exports the following routines into your
namespace:

assert $x - $x is true
assert_true $x - $x is true
assert_false $x - $x is not true
assert_passed - the last eval did not die ($@ eq "")
assert_failed - the last eval caused a die ($@ ne "")
assert_some $x - $x is true
assert_none - $x is false
assert_equals $x, $y - recursively tests arrayrefs, hashrefs
and strings to ensure they have the same
contents
assert_contains $string, $list
- $list contains $string assert_subset
$element_list, $list - $element_list is
a subset of $list (both are arrayrefs)
assert_is_array $x - $x is an arrayref
assert_is_hash $x - $x is a hashref
assert_is_string $x - $x is a scalar
assert_size N, $list - the arrayref contains N elements
assert_keys [k1, k2], $hash
- $hash contains k1, k2 as keys

run_tests_as_script - run all tests in package main and emit
Perls classic "ok/not ok" style output

run_tests_as_script NS1, NS2, ...
- run all tests in package main, NS1,
NS2, and so on and emit Perls classic
"ok/not ok" style output

run_tests - run all tests in package main

run_tests NS1, NS2, ...
- run all tests in package main, NS1,
NS2, and so on

For an example on how to use these assert take a look at
Test/Extreme.pm which includes it own unit tests and
illustrates different ways of using these asserts.

The function run_tests finds all functions that start with
the word test (preceded by zero or more underscores) and runs
them one at a time. It looks in the main namespace by
default and also looks in any namespaces passed to it as
arguments.

Running the tests generates a status line (a "." for every
successful test run, or an "F" for any failed test run), a
summary result line ("OK" or "FAILURES!!!") and zero or more
lines containing detailed error messages for any failed
tests.

To get Perls classic "ok/not ok" style output (which is
useful for writing test scripts) use run_tests_as_script
instead of run_tests.