NAME

STD::Testgen - generates test scripts

SYNOPSIS

use STD::TestGen

$success = STD::TestGen->fgenerate($gen, $std ... $std [\%options])
$success = STD::TestGen->fgenerate($gen, $std, [\%options])

DESCRIPTION

The fgenerate subroutine 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.

Capabilities

The fgenerate subroutine 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 test script that demonstrates the features of the the module under test.
Provide in a 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.
Automate generation of test information required by (STD2167A) from the STD file making it economical to provide this information for even commercial projects. The ISO standards and certification are pushing commercial projects more and more toward using 2167 nomenclature and providing STD2167A information.

Generated files

The fgenerate subroutine will read the data from a .std database file, clean it, and use the cleaned data to generate the output files based on the output option. Unless overriden by an file_out option, the output file is as specified in the input .std database file field for a output option type.

In the unlikely event, the file is not entered in the .std database, the fgenerate subroutine will enter an output file with the same base name as the <$std> file with the extension changed depending upon output option into the .std database. The output file specifications are relative to the .std database file.

Options

The C[%options] hash provides for the following options:

output option

Valid values for output option are

Clean Verify Demo STD

as defined as follows:

Clean output

extension: .std

The generate file contains the clean data from $std.

Verify output

extension: .t

The generated file is a test script.

Demo output

extension: .d

The generated file is a demonstration script.

STD output

extension: -STD.pm

The generated file is a software test description (STD) POD

The fgenerate subroutine will handle multiple values for output option and substitute 'Verify Demo STD' for 'all'. The output option values are case insensitive. For example, 'verify Demo' 'clean all' 'clean STD' are all valid for output option

replace option

replace => 1

run the all demo scripts and use there output to replace the UUT file specified in .std file =headx Demonstration POD section

run option

run => 1

run all generated test scripts using Test::Harness

verbose option

verbose => 1

use verbose mode when using the Test::Harness

file_out option

file_out => $file_name

Use $file_name for the output file when only one output option and one .std are provided.

fspec_out option

Specifies the operating system file specification to use in writing out a cleaned <.std> file output. It overrides the File_Spec Field when writing out a <.std> file.

This directly impacts the following <.std> file fields

Template File_Spec Clean Demo Verify STD

The scope is very limited Valid values are as follows:

MacOS MSWin32 os2 VMS epoc Unix

fspec_in option

the operating file specification for the <.std> input files. The default is Unix.

Valid values are as follows:

MacOS MSWin32 os2 VMS epoc Unix

dir_path option

Normally the fgenerate subroutine looks for the files specified in the .std data base file in all the directories in @INC in order and then in the $ENV{PATH} directories in order.

Supplying a $dir_path, tells the fgenerate subroutine to look in the directories $dir_path before the others.

STD database file format

The primary input for the fgenerate subroutine is .std database files. The suggested file extension is .std. .std file data consists of series of field name and field data pairs.

The format uses separator strings are as follows:

End of Field Name:  [^:]:[^:]
ENd of Field     :  [^\^]\^[^\^]

In other words, the separator strings have a string format of the following:

(not_the_char) . (char) . (not_the_char)

The following are valid FormDB fields:

name: data^

name:
data
 ..
data
^

Separator strings are escaped by added an extra chacater. For example,

DIR:::Module: $data ^

unescaped field name:  DIR::MOdule

DIR::Module:: : $data ^

unescaped field name: DIR:Module:

Since the field name ends in a colon the format requires a space between the field name and the end of field name colon. Since the FormDB format ignores leading and trailing white space for field names, this space is not part of the field name. space.

This is customary form that all of us have been forced to fill out through out our lives with the addition of ending field punctuation. Since the separator sequences are never part of the field name and data, the code to read it is trivial. For being computer friendly it is hard to beat. And, altough most of us are adverse to forms, it makes good try of being people friendly.

An example of a .std file follows:

File_Spec: Unix^
UUT: STD/t/TestGen1.pm^
Revision: -^
End_User: General Public^
Author: http://www.SoftwareDiamonds.com support@SoftwareDiamonds.com^
SVD: SVD: STD-TestGen-0.01^
Template: STD/STD001.frm^
Classification: None^
Clean: STD/t/TestGen1.std^
Demo: STD/t/TestGen1.d^
STD: STD/t/TestGen1-STD.pm^
Verify: STD/t/TestGen1.t^

 T: 0^

 C: use Test::t::TestGen1^

 R: L<Test::t::TestGen1/Description> [1]^

 C: 
    my $x = 2
    my $y = 3
^

 A: $x + $y^
SE: 5^

 N: Two Additions 
 A: ($x+$y,$y-$x)^
 E: (5,1)^

 N: Two Requirements^

 R: 
    L<Test::t::TestGen1/Description> [2]
    L<Test::t::TestGen1/Description> [3]
 ^

 A: ($x+4,$x*$y)^
 E: (6,5)^

 U: ^  Test under development
 S: 1^
 A: $x*$y*2^
 E: 6^

 S: 0^
 A: $x*$y*2^
 E: 6^

See_Also: http://perl.SoftwareDiamonds.com^
Copyright: copyright © 2003 Software Diamonds.^

This is a very compact database form. The actual test code is Perl snippets that will be passed to the appropriate build-in, behind the scenes Perl subroutines.

The following fields are information need to generate the documentation files and not information about the tests themselve:

File_Spec field

the operating system file specification used for the following files:

UUT Template Verify Demo Clean STD

Valid values are Unix MacOS MSWin32 os2 VMS epoc. The scope of this value is very limited. It does not apply to any file specification used in the test steps nor the files used for input to the fgenerate subroutine.

UUT field

The Unit Under Test (UUT) file relative to @INC.

Revision field

Enter the revision for the STD POD. Revision numbers, in accordance with standard engineering drawing practices are letters A .. B AA .. ZZ except for the orginal revision which is -.

End_User field

The prepare for STD title page entry.

Author field

The prepare for STD title page entry.

Classification field

Security classification.

SVD field

The Software Version Description (SVD) file relative to @INC.

Template field

This is the template that the fgenerate subroutine uses to generate the STD file. The fgenerate subroutine merges the following variables with the template in generating the STD file:

Date UUT_PM Revision End_User Author Classification Test_Script SVD Tests STD_PM Test_Descriptions See_Also Trace_Requirement_Table Trace_Test_Table Copyright

The distribution provides the following base STD template

F<STD/STD001.frm>

Copyright field

Any copyright and license requirements. This is integrated into the Demo Script, Test Script and the STD module.

See_Also field

This is integrated into the STD module.

Clean field

The file for the Clean output relative to the .std file directory.

Demo field

The file for the Demo output relative to the .std file directory.

STD field

The file for the STD output relative to the .std file directory.

Verify field

The file for the Verify output relative to the .std file directory.

The fgenerate subroutine strips these fields out and stores them in a hash for use in generating the output files. The fgenerate fucntions converts the File_Spec file specification into the native operating system file specification.

The rest of the of the fields are order sensitive test data as follows:

T: number_of_tests - todo tests

This field provides the number of tests and the number of the todo tests. The fgenerate subroutine will automatically fill in this field.

N: name_data

This field provides a name for the test. This is usually the same name as the base name for the STD file.

X: comment

This field excludes a test from being included in the Demo output file.

R: requirement_data

The requirement_data cites a binding requirement that is verified by the test. The test software uses the requirement_data to automatically generate tracebility information that conforms to the following:

L<STD 4.x.y.1 Requirements addressed.|STD/Military::4.x.y.1 Requirements addressed.>

Many times the relationship between binding requirements and the a test is vague and can even stretch the imagination. Perhaps by tracing the binding requirement down to an actual test number, will help force requirements that have clean cut tests in qualitative terms that can verify and/or validate a requirement.

C: setup-expression

The code are free form Perl code. This is generally used for the following:

L<STD 4.x.y.2 Prerequisite conditions.|Military::STD/4.x.y.2 Prerequisite conditions.>

A: actual-expression

This is the actual Perl expression under test and used for the following:

L<STD 4.x.y.3 Test inputs.|Military::STD/4.x.y.3 Test inputs.>

E: expected-expression

This is the expected results. This should be raw Perl values and used for the following:

L<STD 4.x.y.4 Expected test results.|Military::STD/4.x.y.4 Expected test results.>

This field triggers processing of the previous fields as a test. It must always be the last field of a test. On failure, testing continues.

SE: expected-expression

This is the same as E: expected-expression except that testing stops on failure.

S: expression

The mode S: expression provides means to conditionally preform a test. The condition is usually platform dependent. In other words, a feature may be provided, say for a VMS platform that is not available on a Microsoft platform.

U:

This tags a test as testing a feature or capability under development. The test is added to the todo list.

ok: test_number

The ok: test_number is a the test number that results from the execution of &TEST::ok by the previous E: data or SE: data expression. A STD file does not require any ok: fields since The fgenerate subroutine will automatically generate the ok: test_number fields.

REQUIREMENTS

This section establishes the functional requirements for the STD::TestGen module and the fgenerate subroutine. All other subroutines in the STD::TestGen module and modules used by the STD::TestGen module support the fgenerate subroutine. Their requirements are of a design nature and not included. All design requirements may change at any time without notice to improve performance as long as the change does not impact the functional requirements and the test results of the functional requirements.

Binding functional requirements, in accordance with DOD STD 490A, are uniquely identified with the pharse 'shall[dd]' where dd is an unique number for each section. The phrases such as will, should, and may do not identified binding requirements. They provide clarifications of the requirements and hints for the module design.

The general STD::TestGen Perl module requirements are as follows:

load [1]: shall[1] load without error and
pod check [2]: shall[2] passed the Pod::Checker check without error.

Clean output file requirements

When the output option input list contains clean, case insensitive, the fgenerate subroutine, for each .std input file, will produce a clean ouput file. The Clean output file is basically a carbon copy of the .std input file except as noted below. The requirements for the generated clean output file are as follow:

clean file [1]: The fgenerate subroutine shall[1] obtained the name for the clean output file from the Clean field in the .std database file, convert it from the file specification, in the File_Spec field of the .std database file, to the file specification of the native operating system, and find the file in the @INC and the $ENV{PATH} directory paths.
clean file [2]: The fgenerate subroutine shall[2] ensure there is a test step number field ok: $test_number^ after each E: $expected ^ and each E: $expected^ field. The $test_number will apply to all fields preceding the ok: $test_number^ to the previous ok: $test_number^ or <T: $total_tests^> field
clean file [3]: The fgenerate subroutine shall[4] ensure all test numbers in the ok: test_number^ fields are sequentially numbered.
clean file [4]: The fgenerate subroutine shall[4] ensure the first test field is T: $total_tests^ where $total_tests is the number of ok: $test_number^ fields.
clean file [5]: The fgenerate subroutine shall[5] include a $todo_list in the T: $total_tests - $todo_list^ field where each number in the list is the $test_number for a U: ^ field. If there are no U: ^ fields the T: ^ format will be T: $total_tests^

The fgenerate subroutine will perform this processing as soon as it reads in the .std file. All file generation including the Clean will use the processed, cleaned .std internal test data instead of the raw data directly from the .std file.

Verify output file

When the output option input list contains verify or all, case insensitive, the fgenerate subroutine, for each .std input file, will produce an verify ouput file. The functional requirements specify the results of executing the verify output file. The contents of the verify output file are of a design nature.

The requirements for the generated verify output file are as follow:

verify file [1]: The fgenerate subroutine shall[1] obtained the name for the verify output file from the Verify field in the .std database file and assume it is a UNIX file specification relative to .std database file except when overriden by the file_out option.
verify file [2]: The fgenerate subroutine shall[2] generate a test script that when executed will, for each test, execute the C: $code fields and compared the results obtained from the A: $actual^ actual expression with the results from the E: $epected^ expected expression and produce an output compatible with the <Test::Harness module. A test is the fields between the ok: $test_number fields of a cleaned <$std> file. The fgenerate subroutine will provide skip test functionality by processing the S: $skip-condition test fields and producing suitable <Test::Harness output.
verify file [3]: The fgenerate subroutine shall[3] output the N: $name^ field data as a <Test::Harness compatible comment.

The fgenerate subroutine will properly compare complex data structures produce by the A: $actual^ and E: $epected^ expressions by utilizing modules such as Data::Dumper.

Demo output file

When the output option input list contains demo or all, case insensitive, the fgenerate subroutine, for each .std input file, will produce a demo ouput file. The functional requirements specify the results of executing the demo output file. The contents of the demo output file are of a design nature.

The requirements for the generated demo output file are as follow:

demo file [1]: The fgenerate subroutine shall[1] obtained the name for the demo output file from the Demo field in the .std database file and assume it is a UNIX file specification relative to .std database file except when overriden by the file_out option.
demo file [2]: The fgenerate subroutine shall[2] generate the a demo script that when executed will produce an output that appears as if the actual C: ^ and A: ^ where typed at a console followed by the results of the execution of the A: ^ field. The purpose of the demo script is to provide automated, complete examples, of the using the Unit Under Test.

STD output file

When the output option input list contains STD or all, case insensitive, the fgenerate subroutine, for each .std input file, will produce a STD ouput file. The requirements for the generated STD output file are as follow:

STD file [1]

The fgenerate subroutine shall[1] obtained the name for the STD output file from the STD field in the .std database file and assume it is a UNIX file specification relative to .std database file except when overriden by the file_out option.

STD file [2]

The fgenerate subroutine shall[2] produce the STD output file by taking the merging STD template file from the Template field in the .std database file with the

Copyright Revision End_User Author SVD Classification

fields from the .std and the generated

Date UUT_PM STD_PM Test_Descriptions Test_Script Tests Trace_Requirement_Table Trace_Requirement_Table

fields.

The fgenerate subroutine will generate fields for merging with the template file as follows:

Date: The current data
UUT_PM: The Perl :: module specfication for the UUT field in the .std database
STD_PM: The Perl :: module specification for the .std Unix file specification
Test_Script: The the Verify field in the .std database
Tests: The number of tests in the .std database
Test_Descriptions: A description of a test defined by the fields between ok: fields in the .std database. The test descriptions will be in a STD format as tailored by STDtailor
Trace_Requirement_Table: A table that relates the R: requirement fields to the test number in the .std database.
Trace_Test_Table: A table that relates the test number in the .std database to the R: requirement fields.

The usual template file is the STD/STD001.fmt file. This template is in the STD format as tailored by STDtailor.

Options requirements

The fgenerate option processing requirements are as follows:

file_out option [1]

When the input output option has only one value and there is only one .std input file, specifying the option

{ file_out => $file_out }

shall[1] cause the fgenerate subroutine to print the ouput to the file $file_out instead of the file specified in the .std file. The $file_out specification will be in the UNIX specification relative to the .std database file.

replace option [2]

Specifying the option

{ replace => 1 }

with the output option list containg Demo, shall[2] cause the c<fgenerate> subroutine to execute the demo script that it generates and replace the /(\n=head\d\s+Demonstration).*?\n=/i section in the module named by the UUT field in .std with the output from the demo script.

run option [3]

Specifying the option

{ run => 1 }

with the output option list containg Verify, shall[3] cause the c<fgenerate> subroutine to run the Test::Harness with the test script in non-verbose mode.

verbose option [4]

Specifying the options

{ run => 1, verbose => 1 }

with the output option list containg Verify, shall[4] cause the fgenerate subroutine to run the Test::Harness with the test script in verbose mode.

fspec_out option [5]

Specifying the option

{ fspec_out => I<$file_spec> }

shall[5] cause the fgenerate subroutine to translate the file names in the Clean file output to the file specification $file_spec.

fspec_in option [6]

Specifying the option

{ fspec_in => I<$file_spec> }

shall[6] cause the fgenerate subroutine to translate the files in the input <.std> files from the file specification $file_spec.

dir-path option [7]

Specifying the option

{ dir_path => I<$dir_path> }

shall[7] cause the fgenerate subroutine to seach for the input <.std> file in the directories of $dir_path before looking in the @INC and $ENC{PATH} directories.

DEMONSTRATION

~~~~~~ Demonstration overview ~~~~~

Perl code begins with the prompt

=>

The selected results from executing the Perl Code follow on the next lines. For example,

=> 2 + 2
4

~~~~~~ The demonstration follows ~~~~~

=>     use File::Glob ':glob';
=>     use File::Copy;
=>     my $loaded = 0; 
=>     my @outputs;
=>     my $test_results;
=> $T->load_package( 'STD::TestGen' )
''

=>     #####
=>     # Make sure there is no residue outputs hanging
=>     # around from the last test series.
=>     #
=>     @outputs = bsd_glob( 'tg*1.*' );
=>     unlink @outputs;
=>     @outputs = bsd_glob( 'tg*1-STD.pm');
=>     unlink @outputs;
=> copy 'tgA0.std', 'tgA1.std'
=> $T->fin('tgA1.std')
'

UUT: STD/t/tg1.pm^
Revision: -^
End_User: General Public^
Author: http://www.SoftwareDiamonds.com support@SoftwareDiamonds.com^
SVD: None^
Template: STD/STD001.frm^
Classification: None^
Clean: tgA1.std^
Demo: tgA1.d^
STD: tgA1-STD.pm^
Verify: tgA1.t^

 T: 0^

 C: use STD::t::tg1^

 N: Pass test^
 R: L<STD::t::tg1/capability-A [1]>^
 C: my $x = 2^
 C: my $y = 3^
 A: $x + $y^
SE: '5'^

 N: Todo test that passes^
 U: xy feature^
 A: ($x+$y,$y-$x)^
 E: '5','1'^

 R: 
    L<STD::t::tg1/capability-A [2]>
    L<STD::t::tg1/Capability-B [1]>
 ^
 N: Test that fails^
 A: ($x+4,$x*$y)^
 E: '6','5'^

 N: Skipped tests^
 S: 1^
 A: $x*$y*2^
 E: '6'^

 N: Todo Test that Fails^
 U: zyw feature^
 S: 0^
 A: $x*$y*2^
 E: '6'^

 N: Failed test that skips the rest^
 R: L<STD::t::tg1/Capability-B [2]>^
 A: $x + $y^
SE: '6'^

 N: A test to skip^
 A: $x + $y + $x^
 E: '9'^

 N: A not skip to skip^
 S: 0^
 R: L<STD::t::tg1/Capability-B [3]>^
 A: $x + $y + $x + $y^
 E: '10'^

 N: A skip to skip^
 S: 1^
 R: L<STD::t::tg1/Capability-B [3]>^
 A: $x + $y + $x + $y + $x^
 E: '10'^

See_Also: 
http://perl.softwarediamonds.com
L<STD::t::tg1>
^

Copyright: Public Domain^

'

=> copy 'tg0.pm', 'tg1.pm'
=> $T->fin('tg1.pm')
'#!perl
#
# Documentation, copyright and license is at the end of this file.
#
package  Test::t::Case0A;

use 5.001;
use strict;
use warnings;
use warnings::register;

use vars qw($VERSION);

$VERSION = '0.01';

1

__END__

=head1 Requirements

=head2 Capability-A 

The requriements are as follows:

=over 4

=item capability-A [1]

This subroutine shall[1] have feature 1. 

=item capability-A [2]

This subroutine shall[2] have feature 2.

=back

=head2 Capability-B

=over 4

=item Capability-B [1]

This subroutine shall[1] have feature 1.

=item Capability-B [2]

This subroutine shall[2] have feature 2.

=item Capability-B [3]

This subroutine shall[3] have feature 3.

=back

=head1 DEMONSTRATION

=head1 SEE ALSO

http://perl.SoftwareDiamonds.com

'

=> copy 'tgA0.std', 'tgA1.std'
=> STD::TestGen->fgenerate('STD/t/tgA1.std', {fspec_in=>'Unix', output=>'clean all'} )
=> $T->fin('tgA1.std')
'

File_Spec: Unix^
UUT: STD/t/tg1.pm^
Revision: -^
End_User: General Public^
Author: http://www.SoftwareDiamonds.com support@SoftwareDiamonds.com^
SVD: None^
Template: STD/STD001.frm^
Classification: None^
Clean: tgA1.std^
Demo: tgA1.d^
STD: tgA1-STD.pm^
Verify: tgA1.t^

 T: 9 - 2,5^

 C: use STD::t::tg1^
 N: Pass test^
 R: L<STD::t::tg1/capability-A [1]>^
 C: my $x = 2^
 C: my $y = 3^
 A: $x + $y^
SE: '5'^
ok: 1^

 N: Todo test that passes^
 U: xy feature^
 A: ($x+$y,$y-$x)^
 E: '5','1'^
ok: 2^

 R:
    L<STD::t::tg1/capability-A [2]>
    L<STD::t::tg1/Capability-B [1]>
^

 N: Test that fails^
 A: ($x+4,$x*$y)^
 E: '6','5'^
ok: 3^

 N: Skipped tests^
 S: 1^
 A: $x*$y*2^
 E: '6'^
ok: 4^

 N: Todo Test that Fails^
 U: zyw feature^
 S: 0^
 A: $x*$y*2^
 E: '6'^
ok: 5^

 N: Failed test that skips the rest^
 R: L<STD::t::tg1/Capability-B [2]>^
 A: $x + $y^
SE: '6'^
ok: 6^

 N: A test to skip^
 A: $x + $y + $x^
 E: '9'^
ok: 7^

 N: A not skip to skip^
 S: 0^
 R: L<STD::t::tg1/Capability-B [3]>^
 A: $x + $y + $x + $y^
 E: '10'^
ok: 8^

 N: A skip to skip^
 S: 1^
 R: L<STD::t::tg1/Capability-B [3]>^
 A: $x + $y + $x + $y + $x^
 E: '10'^
ok: 9^

See_Also:
http://perl.softwarediamonds.com
L<STD::t::tg1>
^

Copyright: Public Domain^

'

=> STD::TestGen->fgenerate('STD/t/tgA1.std', {fspec_in=>'Unix', output=>'demo', replace => 1});
=> $T->fin('tg1.pm')
'#!perl
#
# Documentation, copyright and license is at the end of this file.
#
package  Test::t::Case0A;

use 5.001;
use strict;
use warnings;
use warnings::register;

use vars qw($VERSION);

$VERSION = '0.01';

1

__END__

=head1 Requirements

=head2 Capability-A 

The requriements are as follows:

=over 4

=item capability-A [1]

This subroutine shall[1] have feature 1. 

=item capability-A [2]

This subroutine shall[2] have feature 2.

=back

=head2 Capability-B

=over 4

=item Capability-B [1]

This subroutine shall[1] have feature 1.

=item Capability-B [2]

This subroutine shall[2] have feature 2.

=item Capability-B [3]

This subroutine shall[3] have feature 3.

=back

=head1 DEMONSTRATION

 ~~~~~~ Demonstration overview ~~~~~

Perl code begins with the prompt

 =>

The selected results from executing the Perl Code 
follow on the next lines. For example,

 => 2 + 2
 4

 ~~~~~~ The demonstration follows ~~~~~

 => use STD::t::tg1
 => my $x = 2
 => my $y = 3
 => $x + $y
 '5'

 => ($x+$y,$y-$x)
 '5'
 '1'

 => ($x+4,$x*$y)
 '6'
 '6'

 => $x*$y*2
 '12'

 => $x + $y
 '5'

 => $x + $y + $x
 '7'

 => $x + $y + $x + $y
 '10'

=head1 SEE ALSO

http://perl.SoftwareDiamonds.com

'

=>     no warnings;
=>     open SAVEOUT, ">&STDOUT";
=>     open STDOUT, ">tgA1.txt";
=>     STD::TestGen->fgenerate('STD/t/tgA1.std', {fspec_in=>'Unix', output=>'verify', run=>1, verbose=>1});
=>     close STDOUT;
=>     open STDOUT, ">&SAVEOUT";
=>     use warnings;
=>     
=>     ######
=>     # For some reason, test harness puts in a extra line when running u
=>     # under the Active debugger on Win32. So just take it out.
=>     # Also the script name is absolute which is site dependent.
=>     # Take it out of the comparision.
=>     #
=>     $test_results = $T->fin('tgA1.txt');
=>     $test_results =~ s/.*?1..9/1..9/; 
=>     $test_results =~ s/------.*?\n(\s*\()/\n $1/s;
=>     $T->fout('TgA1.txt',$test_results);
=> $test_results
'1..9 todo 2 5;
# Pass test
ok 1
# Todo test that passes
ok 2 # (E:\User\SoftwareDiamonds\installation\lib\STD\t\tgA1.t at line 109 TODO?!)
# Test that fails
not ok 3
# Test 3 got: '$VAR1 = '6';
$VAR2 = '6';
' (E:\User\SoftwareDiamonds\installation\lib\STD\t\tgA1.t at line 123)
#   Expected: '$VAR1 = '6';
$VAR2 = '5';
'
# Skipped tests
ok 4 # skip
# Todo Test that Fails
not ok 5
# Test 5 got: '$VAR1 = '12';
' (E:\User\SoftwareDiamonds\installation\lib\STD\t\tgA1.t at line 139 *TODO*)
#   Expected: '$VAR1 = '6';
'
# Failed test that skips the rest
not ok 6
# Test 6 got: '$VAR1 = '5';
' (E:\User\SoftwareDiamonds\installation\lib\STD\t\tgA1.t at line 153)
#   Expected: '$VAR1 = '6';
'
# A test to skip
# Test invalid because of previous failure.
ok 7 # skip
# A not skip to skip
# Test invalid because of previous failure.
ok 8 # skip
# A skip to skip
# Test invalid because of previous failure.
ok 9 # skip
FAILED tests 3, 6
	Failed 2/9 tests, 77.78% okay (-4 skipped tests: 3 okay, 33.33%)
Failed Test                      Status Wstat Total Fail  Failed  List of Failed

  (1 subtest UNEXPECTEDLY SUCCEEDED), 4 subtests skipped.
Failed 1/1 test scripts, 0.00% okay. 2/9 subtests failed, 77.78% okay.
'

=>     sub __warn__ 
=>     { 
=>        my ($text) = @_;
=>        return $text =~ /STDOUT/;
=>        CORE::warn( $text );
=>     };

=>     #####
=>     # Make sure there is no residue outputs hanging
=>     # around from the last test series.
=>     #
=>     @outputs = bsd_glob( 'tg*1.*' );
=>     unlink @outputs;
=>     @outputs = bsd_glob( 'tg*1-STD.pm');
=>     unlink @outputs;

QUALITY ASSURANCE

The file STD/t/testgen.std is the Software Test Description file for the Test::Testgen module. This file contains all the information necessary for this module to verify that this module meets its requirements. In other words, this module will verify itself. This is valid because if something is wrong with this module, it will not be able to verify itself. And if it cannot verify itself, it cannot verify that another module meets its requirements.

To generate all the test output files, run the generated test script Test/t/Testgen.t and the demonstration script Test/t/Testgen.d, execute the following in the Test/t directory:

tg -o="clean all" -v -r -e STD/t/TestGen.std

NOTES

Binding Requirements

In accordance with the License, Software Diamonds is not liable for any requirement, binding or otherwise.

Author

The author, holder of the copyright and maintainer is

<support@SoftwareDiamonds.com>

Copyright

License

Software Diamonds permits the redistribution and use in source and binary forms, with or without modification, provided that the following conditions are met:

Redistributions of source code, modified or unmodified must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

SOFTWARE DIAMONDS, http://www.SoftwareDiamonds.com, PROVIDES THIS SOFTWARE 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL SOFTWARE DIAMONDS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING USE OF THIS SOFTWARE, EVEN IF ADVISED OF NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE POSSIBILITY OF SUCH DAMAGE.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)

NAME

SYNOPSIS

DESCRIPTION

Capabilities

Generated files

Options

STD database file format

REQUIREMENTS

Clean output file requirements

Verify output file

Demo output file

STD output file

Options requirements

DEMONSTRATION

QUALITY ASSURANCE

NOTES

Binding Requirements

Author

Copyright

License

SEE ALSO

Module Install Instructions