test data
Sponsored Links
Sponsored Links
Secleted [ 0 ] software to compare
Results 1 - 15 of about 6862
Test::Data 1.20
Test::Data is a Perl module to test functions for particular variable types. more>>
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.
<<lessSYNOPSIS
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.
Download (0.008MB)
Added: 2007-05-03 License: Perl Artistic License Price:
904 downloads
Test::TempDatabase 0.1
Test::TempDatabase is a Perl module for temporary database creation and destruction. more>>
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.
<<lessSYNOPSIS
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.
Download (0.011MB)
Added: 2007-05-08 License: Perl Artistic License Price:
899 downloads
TestGen4J 0.1.4-alpha
TestGen4J automatically generates JUnit test cases from your own Java class files or source files. more>>
TestGen4J automatically generates JUnit test cases from your own Java class files or source files.
Its primary focus is to exercise boundary value testing of the arguments passed to the method. It uses rules, written in a user-configurable XML file, that define boundary conditions for the data types.
The test code is separated from test data with the help of JTestCase. The test code is generated in a hierarchical manner.
Enhancements:
- This release fixes a problem in which tests are not generated for a method whose return type is an object of an inner-class of some other main class if this inner-class is private or if it not private but the main class does not have a public constructor.
- SpikeTestGen.java was changed to look for methods returning an object which are inner-classes.
<<lessIts primary focus is to exercise boundary value testing of the arguments passed to the method. It uses rules, written in a user-configurable XML file, that define boundary conditions for the data types.
The test code is separated from test data with the help of JTestCase. The test code is generated in a hierarchical manner.
Enhancements:
- This release fixes a problem in which tests are not generated for a method whose return type is an object of an inner-class of some other main class if this inner-class is private or if it not private but the main class does not have a public constructor.
- SpikeTestGen.java was changed to look for methods returning an object which are inner-classes.
Download (0.83MB)
Added: 2005-11-04 License: Open Software License Price:
1457 downloads
Test::Cmd 1.05
Test::Cmd is a Perl module for portable testing of commands and scripts. more>>
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.
<<lessSYNOPSIS
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.
Download (0.030MB)
Added: 2007-02-23 License: Perl Artistic License Price:
978 downloads
Test soon 0.59
Test soon project is a testing framework trying to enable you to write tests quickly. more>>
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.
<<lessThe goal is to utilize the strengths of C++ while minimizing the impact of its weaknesses.
Download (MB)
Added: 2007-07-01 License: zlib/libpng License Price:
846 downloads
Test::STDmaker 0.23
Test::STDmaker is a Perl module to generate test scripts, demo scripts from a test description short hand. more>>
Test::STDmaker is a Perl module to generate test scripts, demo scripts from a test description short hand.
SYNOPSIS
#######
# Procedural (subroutine) interface
#
use Test::STDmake qw(find_t_roots get_data perl_command);
@t_path = find_t_paths()
$date = get_date();
$myperl = perl_command();
#####
# Class interface
#
use Test::STDmaker
$std = new Test::STDmaker( @options ); # From File::Maker
$success = $std->check_db($std_pm);
@t_path = $std->find_t_paths()
$date = $std->get_date();
$myperl = $std->perl_command();
$std->tmake( @targets, %options );
$std->tmake( @targets );
$std->tmake( %options );
######
# Internal (Private) Methods
#
$success = $std->build($std_driver_class);
$success = $std->generate();
$success = $std->print($file_out);
The Test::STDmaker program module provides the following capabilities:
Automate Perl related programming needed to create a test script resulting in reduction of time and cost.
Translate a short hand Software Test Description (STD) file into a Perl test script that eventually makes use of the Test module.
Translate the sort hand STD data file into a Perl demo script that demonstrates the features of the the module under test.
Provide in the POD of a STD file information required by a Military/Federal Government Software Test Description (STD) document that may easily be index and accessed by automated Test software. ISO, British Military require most of the same information, US agencies such as the FAA. The difference is that ISO, British Military do not dictate detail format. US agencies such as FAA will generally tailor down the DOD required formats.
Thus, there is an extremely wide variation in the format of the same information among ISO certified comericial activities and militaries other than US. Once the information is in a POD, different translators may format nearly exactly as dictated by the end user, whether it is the US DOD, ISO certified commericial activity, British Military or whoever. By being able to provide the most demanding, which is usually US DOD, the capabilities are there for all the others.
The Test::STDmaker package relieves the designer and developer from the burden of filling out word processor boiler plate templates (whether run-off, Word, or vi), counting oks, providing documentation examples, tracing tests to test requirments, making sure it is in the proper corporate, ISO or military format, and other such extremely time consuming, boring, development support tasks. Instead the designers and developers need only to fill in a form using a test description short hand. The Test::STDmaker will take it from there and automatically and quickly generate the desired test scripts, demo scripts, and test description documents.
Look at the economics. It does not make economically sense to have expensive talent do this work. In does not even make economically sense to take a bright 16 year, at mimimum wage and have him manually count oks. Perl can count those oks much much cheaper and it is so easily to automated with Perl. And something like this were you are doing it year in and year out, the saving are enormous. To a program manager or contract officer, this is what programming and computers are all about, saving money and increasing productivity, not object oriented oriented programing, gotos or other such things.
The Test::STDmaker class package automates the generation of Software Test Descriptions (STD) Plain Old Documentation (POD), test scripts, demonstrations scripts and the execution of the generated test scripts and demonstration scripts. It will automatically insert the output from the demonstration script into the POD -headx Demonstration section of the file being tested.
<<lessSYNOPSIS
#######
# Procedural (subroutine) interface
#
use Test::STDmake qw(find_t_roots get_data perl_command);
@t_path = find_t_paths()
$date = get_date();
$myperl = perl_command();
#####
# Class interface
#
use Test::STDmaker
$std = new Test::STDmaker( @options ); # From File::Maker
$success = $std->check_db($std_pm);
@t_path = $std->find_t_paths()
$date = $std->get_date();
$myperl = $std->perl_command();
$std->tmake( @targets, %options );
$std->tmake( @targets );
$std->tmake( %options );
######
# Internal (Private) Methods
#
$success = $std->build($std_driver_class);
$success = $std->generate();
$success = $std->print($file_out);
The Test::STDmaker program module provides the following capabilities:
Automate Perl related programming needed to create a test script resulting in reduction of time and cost.
Translate a short hand Software Test Description (STD) file into a Perl test script that eventually makes use of the Test module.
Translate the sort hand STD data file into a Perl demo script that demonstrates the features of the the module under test.
Provide in the POD of a STD file information required by a Military/Federal Government Software Test Description (STD) document that may easily be index and accessed by automated Test software. ISO, British Military require most of the same information, US agencies such as the FAA. The difference is that ISO, British Military do not dictate detail format. US agencies such as FAA will generally tailor down the DOD required formats.
Thus, there is an extremely wide variation in the format of the same information among ISO certified comericial activities and militaries other than US. Once the information is in a POD, different translators may format nearly exactly as dictated by the end user, whether it is the US DOD, ISO certified commericial activity, British Military or whoever. By being able to provide the most demanding, which is usually US DOD, the capabilities are there for all the others.
The Test::STDmaker package relieves the designer and developer from the burden of filling out word processor boiler plate templates (whether run-off, Word, or vi), counting oks, providing documentation examples, tracing tests to test requirments, making sure it is in the proper corporate, ISO or military format, and other such extremely time consuming, boring, development support tasks. Instead the designers and developers need only to fill in a form using a test description short hand. The Test::STDmaker will take it from there and automatically and quickly generate the desired test scripts, demo scripts, and test description documents.
Look at the economics. It does not make economically sense to have expensive talent do this work. In does not even make economically sense to take a bright 16 year, at mimimum wage and have him manually count oks. Perl can count those oks much much cheaper and it is so easily to automated with Perl. And something like this were you are doing it year in and year out, the saving are enormous. To a program manager or contract officer, this is what programming and computers are all about, saving money and increasing productivity, not object oriented oriented programing, gotos or other such things.
The Test::STDmaker class package automates the generation of Software Test Descriptions (STD) Plain Old Documentation (POD), test scripts, demonstrations scripts and the execution of the generated test scripts and demonstration scripts. It will automatically insert the output from the demonstration script into the POD -headx Demonstration section of the file being tested.
Download (0.13MB)
Added: 2007-01-11 License: Perl Artistic License Price:
1016 downloads
Test::Tech 0.26
Test::Tech is a Perl module that adds skip_tests and test data structures capabilities to the Test module. more>>
Test::Tech is a Perl module that adds skip_tests and test data structures capabilities to the "Test" module.
SYNOPSIS
#######
# Procedural (subroutine) Interface
#
# (use for &Test::plan, &Test::ok, &Test::skip drop in)
#
use Test::Tech qw(demo finish is_skip ok ok_sub plan skip skip_sub
skip_tests stringify tech_config);
demo($quoted_expression, @expression);
(@stats) = finish( );
$num_passed = finish( );
$skip_on = is_skip( );
($skip_on, $skip_diag) = is_skip( );
$test_ok = ok($actual_results, $expected_results, [@options]);
$test_ok = ok($actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = ok($actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = ok_sub(⊂routine, $actual_results, $expected_results, [@options]);
$test_ok = ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$success = plan(@args);
$test_ok = skip($skip_test, $actual_results, $expected_results, [@options]);
$test_ok = skip($skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = skip($skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, [@options]);
$test_ok = skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$skip_on = skip_tests( $on_off, $skip_diagnostic);
$skip_on = skip_tests( $on_off );
$skip_on = skip_tests( );
$string = stringify($var, @options); # imported from Data::Secs2
$new_value = tech_config( $key, $old_value);
#####
# Object Interface
#
$tech = new Test::Tech;
$tech->demo($quoted_expression, @expression)
(@stats) = $tech->finish( );
$num_passed = $tech->finish( );
$skip_on = $tech->is_skip( );
($skip_on, $skip_diag) = $tech->is_skip( );
$test_ok = $tech->ok($actual_results, $expected_results, [@options]);
$test_ok = $tech->ok($actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->ok($actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = $tech->ok_sub(⊂routine, $actual_results, $expected_results, [@options]);
$test_ok = $tech->ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$success = $tech->plan(@args);
$test_ok = $tech->skip($skip_test, $actual_results, $expected_results, [@options]);
$test_ok = $tech->skip($skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->skip($skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = $tech->skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, [@options]);
$test_ok = $tech->skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$state = $tech->skip_tests( );
$state = $tech->skip_tests( $on_off );
$state = skip_tests( $on_off, $skip_diagnostic );
$string = $tech->stringify($var, @options); # imported from Data::Secs2
$new_value = $tech->tech_config($key, $old_value);
Generally, if a subroutine will process a list of options, @options, that subroutine will also process an array reference, @options, [@options], or hash reference, %options, {@options}. If a subroutine will process an array reference, @options, [@options], that subroutine will also process a hash reference, %options, {@options}. See the description for a subroutine for details and exceptions.
<<lessSYNOPSIS
#######
# Procedural (subroutine) Interface
#
# (use for &Test::plan, &Test::ok, &Test::skip drop in)
#
use Test::Tech qw(demo finish is_skip ok ok_sub plan skip skip_sub
skip_tests stringify tech_config);
demo($quoted_expression, @expression);
(@stats) = finish( );
$num_passed = finish( );
$skip_on = is_skip( );
($skip_on, $skip_diag) = is_skip( );
$test_ok = ok($actual_results, $expected_results, [@options]);
$test_ok = ok($actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = ok($actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = ok_sub(⊂routine, $actual_results, $expected_results, [@options]);
$test_ok = ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$success = plan(@args);
$test_ok = skip($skip_test, $actual_results, $expected_results, [@options]);
$test_ok = skip($skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = skip($skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, [@options]);
$test_ok = skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$skip_on = skip_tests( $on_off, $skip_diagnostic);
$skip_on = skip_tests( $on_off );
$skip_on = skip_tests( );
$string = stringify($var, @options); # imported from Data::Secs2
$new_value = tech_config( $key, $old_value);
#####
# Object Interface
#
$tech = new Test::Tech;
$tech->demo($quoted_expression, @expression)
(@stats) = $tech->finish( );
$num_passed = $tech->finish( );
$skip_on = $tech->is_skip( );
($skip_on, $skip_diag) = $tech->is_skip( );
$test_ok = $tech->ok($actual_results, $expected_results, [@options]);
$test_ok = $tech->ok($actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->ok($actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = $tech->ok_sub(⊂routine, $actual_results, $expected_results, [@options]);
$test_ok = $tech->ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->ok_sub(⊂routine, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$success = $tech->plan(@args);
$test_ok = $tech->skip($skip_test, $actual_results, $expected_results, [@options]);
$test_ok = $tech->skip($skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->skip($skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$test_ok = $tech->skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, [@options]);
$test_ok = $tech->skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, [@options]);
$test_ok = $tech->skip_sub(⊂routine, $skip_test, $actual_results, $expected_results, $diagnostic, $test_name, [@options]);
$state = $tech->skip_tests( );
$state = $tech->skip_tests( $on_off );
$state = skip_tests( $on_off, $skip_diagnostic );
$string = $tech->stringify($var, @options); # imported from Data::Secs2
$new_value = $tech->tech_config($key, $old_value);
Generally, if a subroutine will process a list of options, @options, that subroutine will also process an array reference, @options, [@options], or hash reference, %options, {@options}. If a subroutine will process an array reference, @options, [@options], that subroutine will also process a hash reference, %options, {@options}. See the description for a subroutine for details and exceptions.
Download (0.091MB)
Added: 2007-02-15 License: Perl Artistic License Price:
981 downloads
Test-Parser 1.2
Test::Parser is a collection of parsers for different test output file formats. more>>
Test::Parser is a collection of parsers for different test output file formats. These parse the data into a general purpose data structure that can then be used to create reports, do post-processing analysis, etc.
Test-Parser can also export tests in SpikeSources TRPI test description XML language.
<<lessTest-Parser can also export tests in SpikeSources TRPI test description XML language.
Download (0.053MB)
Added: 2006-05-04 License: GPL (GNU General Public License) Price:
1268 downloads
JTestCase 4.0.0
JTestCase is a 100% pure Java, open-source framework that helps in separating test case data from test case units. more>>
JTestCase is a 100% pure Java, open-source framework that helps in separating test case data from test case units.
Although the following examples show JTestCase used together with junit, please note that JTestCase has no dependence on junit itself.
A moderately complex java projects may comprise hundreds of junit test case. JTestCase helps you organize your test cases in a rationale and efficient way.
To achieve this goal JTestCase provides:
- A propetary XML format to define your test cases in an abstract way.
- Easy-to-use API to retrieve data from XML file and to do assertion.
<<lessAlthough the following examples show JTestCase used together with junit, please note that JTestCase has no dependence on junit itself.
A moderately complex java projects may comprise hundreds of junit test case. JTestCase helps you organize your test cases in a rationale and efficient way.
To achieve this goal JTestCase provides:
- A propetary XML format to define your test cases in an abstract way.
- Easy-to-use API to retrieve data from XML file and to do assertion.
Download (0.64MB)
Added: 2006-08-19 License: GPL (GNU General Public License) Price:
1162 downloads
Test::More 0.70
Test::More is yet another framework for writing test scripts. more>>
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.
<<lessSYNOPSIS
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.
Download (0.076MB)
Added: 2007-05-04 License: Perl Artistic License Price:
540 downloads
Test-Run 0.0110
Test-Run is an improved test harness for scripts that emit TAP (Test Anything Protocol). more>>
Test-Run is an improved test harness for scripts that emit TAP (Test Anything Protocol). It was forked from Test::Harness, and it uses TAP::Parser.
The project is used to analyze the output of the scripts and present it to the user in a summarized form. Test-Run features separation of the test-running backend and the command line frontend, a "runprove" utility for running tests from the command line, a plugin-system, and colors for the summary line.
<<lessThe project is used to analyze the output of the scripts and present it to the user in a summarized form. Test-Run features separation of the test-running backend and the command line frontend, a "runprove" utility for running tests from the command line, a plugin-system, and colors for the summary line.
Download (0.067MB)
Added: 2007-06-12 License: MIT/X Consortium License Price:
865 downloads
CGI::Test 0.104
CGI::Test is a CGI regression test framework. more>>
CGI::Test is a CGI regression test framework.
SYNOPSIS
# In some t/script.t regression test, for instance
use CGI::Test; # exports ok()
my $ct = CGI::Test->new(
-base_url => "http://some.server:1234/cgi-bin",
-cgi_dir => "/path/to/cgi-bin",
);
my $page = $ct->GET("http://some.server:1234/cgi-bin/script?arg=1");
ok 1, $page->content_type =~ m|text/htmlb|;
my $form = $page->forms->[0];
ok 2, $form->action eq "/cgi-bin/some_target";
my $menu = $form->menu_by_name("months");
ok 3, $menu->is_selected("January");
ok 4, !$menu->is_selected("March");
ok 5, $menu->multiple;
my $send = $form->submit_by_name("send_form");
ok 6, defined $send;
#
# Now interact with the CGI
#
$menu->select("March"); # "click" on the March label
my $answer = $send->press; # "click" on the send button
ok 7, $answer->is_ok; # and make sure we dont get an HTTP error
The CGI::Test module provides a CGI regression test framework which allows you to run your CGI programs offline, i.e. outside a web server, and interact with them programmatically, without the need to type data and click from a web browser.
If youre using the CGI module, you may be familiar with its offline testing mode. However, this mode is appropriate for simple things, and there is no support for conducting a full session with a stateful script. CGI::Test fills this gap by providing the necessary infrastructure to run CGI scripts, then parse the output to construct objects that can be queried, and on which you can interact to "play" with the scripts control widgets, finally submitting data back. And so on...
Note that the CGI scripts you can test with CGI::Test need not be implemented in Perl at all. As far as this framework is concerned, CGI scripts are executables that are run on a CGI-like environment and which produce an output.
To use the CGI::Test framework, you need to configure a CGI::Test object to act like a web server, by providing the URL base where CGI scripts lie on this pseudo-server, and which physical directory corresponds to that URL base.
From then on, you may issue GET and POST requests giving an URL, and the pseudo-server returns a CGI::Test::Page object representing the outcome of the request. This page may be an error, plain text, some binary data, or an HTML page (see CGI::Test::Page for details).
The latter (an HTML page) can contain one or more CGI forms (identified by tags), which are described by instances of CGI::Test::Form objects (see CGI::Test::Form for details).
Forms can be queried to see whether they contain a particular type of widget (menu, text area, button, etc...), of a particular name (thats the CGI parameter name). Once found, one may interact with a widget as the user would from a browser. Widgets are described by polymorphic objects which conform to the CGI::Test::Form::Widget type. The specific interaction that is offered depends on the dynamic type of the object (see CGI::Test::Form::Widget for details).
An interaction with a form ends by a submission of the form data to the server, and getting a reply back. This is done by pressing a submit button, and the press() routine returns a new page. Naturally, no server is contacted at all within the CGI::Test framework, and the CGI script is ran through a proper call to one of the GET/POST method on the CGI::Test object.
Finally, since CGI::Test is meant to be used from regression test scripts, it exports a single ok() routine which merely prints the messages expected by Test::Harness. This is the only functional routine in this module, all other accesses being made through a CGI::Test object.
<<lessSYNOPSIS
# In some t/script.t regression test, for instance
use CGI::Test; # exports ok()
my $ct = CGI::Test->new(
-base_url => "http://some.server:1234/cgi-bin",
-cgi_dir => "/path/to/cgi-bin",
);
my $page = $ct->GET("http://some.server:1234/cgi-bin/script?arg=1");
ok 1, $page->content_type =~ m|text/htmlb|;
my $form = $page->forms->[0];
ok 2, $form->action eq "/cgi-bin/some_target";
my $menu = $form->menu_by_name("months");
ok 3, $menu->is_selected("January");
ok 4, !$menu->is_selected("March");
ok 5, $menu->multiple;
my $send = $form->submit_by_name("send_form");
ok 6, defined $send;
#
# Now interact with the CGI
#
$menu->select("March"); # "click" on the March label
my $answer = $send->press; # "click" on the send button
ok 7, $answer->is_ok; # and make sure we dont get an HTTP error
The CGI::Test module provides a CGI regression test framework which allows you to run your CGI programs offline, i.e. outside a web server, and interact with them programmatically, without the need to type data and click from a web browser.
If youre using the CGI module, you may be familiar with its offline testing mode. However, this mode is appropriate for simple things, and there is no support for conducting a full session with a stateful script. CGI::Test fills this gap by providing the necessary infrastructure to run CGI scripts, then parse the output to construct objects that can be queried, and on which you can interact to "play" with the scripts control widgets, finally submitting data back. And so on...
Note that the CGI scripts you can test with CGI::Test need not be implemented in Perl at all. As far as this framework is concerned, CGI scripts are executables that are run on a CGI-like environment and which produce an output.
To use the CGI::Test framework, you need to configure a CGI::Test object to act like a web server, by providing the URL base where CGI scripts lie on this pseudo-server, and which physical directory corresponds to that URL base.
From then on, you may issue GET and POST requests giving an URL, and the pseudo-server returns a CGI::Test::Page object representing the outcome of the request. This page may be an error, plain text, some binary data, or an HTML page (see CGI::Test::Page for details).
The latter (an HTML page) can contain one or more CGI forms (identified by tags), which are described by instances of CGI::Test::Form objects (see CGI::Test::Form for details).
Forms can be queried to see whether they contain a particular type of widget (menu, text area, button, etc...), of a particular name (thats the CGI parameter name). Once found, one may interact with a widget as the user would from a browser. Widgets are described by polymorphic objects which conform to the CGI::Test::Form::Widget type. The specific interaction that is offered depends on the dynamic type of the object (see CGI::Test::Form::Widget for details).
An interaction with a form ends by a submission of the form data to the server, and getting a reply back. This is done by pressing a submit button, and the press() routine returns a new page. Naturally, no server is contacted at all within the CGI::Test framework, and the CGI script is ran through a proper call to one of the GET/POST method on the CGI::Test object.
Finally, since CGI::Test is meant to be used from regression test scripts, it exports a single ok() routine which merely prints the messages expected by Test::Harness. This is the only functional routine in this module, all other accesses being made through a CGI::Test object.
Download (0.050MB)
Added: 2007-06-12 License: Perl Artistic License Price:
864 downloads
Test::ISBN 1.09
Test::ISBN is a Perl module to check international standard book numbers. more>>
Test::ISBN is a Perl module to check international standard book numbers.
SYNOPSIS
use Test::More tests => 1;
use Test::ISBN;
isbn_ok( $isbn );
Functions
isbn_ok( STRING )
Ok is the STRING is a valid ISBN, in any format that Business::ISBN accepts. This function only checks the checksum. The publisher and country codes might be invalid even though the checksum is valid.
isbn_country_ok( STRING, COUNTRY )
Ok is the STRING is a valid ISBN and its country code is the same as COUNTRY.
isbn_publisher_ok( STRING, PUBLISHER )
Ok is the STRING is a valid ISBN and its publisher code is the same as PUBLISHER.
<<lessSYNOPSIS
use Test::More tests => 1;
use Test::ISBN;
isbn_ok( $isbn );
Functions
isbn_ok( STRING )
Ok is the STRING is a valid ISBN, in any format that Business::ISBN accepts. This function only checks the checksum. The publisher and country codes might be invalid even though the checksum is valid.
isbn_country_ok( STRING, COUNTRY )
Ok is the STRING is a valid ISBN and its country code is the same as COUNTRY.
isbn_publisher_ok( STRING, PUBLISHER )
Ok is the STRING is a valid ISBN and its publisher code is the same as PUBLISHER.
Download (0.004MB)
Added: 2007-05-04 License: Perl Artistic License Price:
903 downloads
Test::Glade 1.0
Test::Glade is a simple way to test Gtk2::GladeXML-based apps. more>>
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.
<<lessSYNOPSIS
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.
Download (0.005MB)
Added: 2007-05-04 License: Perl Artistic License Price:
903 downloads
Test::Unit 0.25
Test::Unit is the main PerlUnit testing framework. more>>
Test::Unit is the main PerlUnit testing framework.
SYNOPSIS
This package provides only the project version number, copyright texts, and a framework overview in POD format.
This framework is intended to support unit testing in an object-oriented development paradigm (with support for inheritance of tests etc.) and is derived from the JUnit testing framework for Java by Kent Beck and Erich Gamma. To start learning how to use this framework, see Test::Unit::TestCase and Test::Unit::TestSuite. (There will also eventually be a tutorial in Test::Unit::Tutorial.
However Test::Unit::Procedural is the procedural style interface to a sophisticated unit testing framework for Perl that . Test::Unit is intended to provide a simpler interface to the framework that is more suitable for use in a scripting style environment. Therefore, Test::Unit does not provide much support for an object-oriented approach to unit testing.
<<lessSYNOPSIS
This package provides only the project version number, copyright texts, and a framework overview in POD format.
This framework is intended to support unit testing in an object-oriented development paradigm (with support for inheritance of tests etc.) and is derived from the JUnit testing framework for Java by Kent Beck and Erich Gamma. To start learning how to use this framework, see Test::Unit::TestCase and Test::Unit::TestSuite. (There will also eventually be a tutorial in Test::Unit::Tutorial.
However Test::Unit::Procedural is the procedural style interface to a sophisticated unit testing framework for Perl that . Test::Unit is intended to provide a simpler interface to the framework that is more suitable for use in a scripting style environment. Therefore, Test::Unit does not provide much support for an object-oriented approach to unit testing.
Download (0.31MB)
Added: 2007-05-07 License: Perl Artistic License Price:
900 downloads
Secleted [ 0 ] software to compare
Copyright Notice:
Software piracy is theft, Using crack, password, serial numbers, registration codes, key generators is illegal and prevent future software development. The above test data search only lists software in full, demo and trial versions for free download. Download links are directly from our mirror sites or publisher sites, torrent files or links from rapidshare.com, yousendit.com or megaupload.com are not allowed
