NAME

Parrot::Configure::Step::Test - Populate Parrot::Configure object with results of configuration

SYNOPSIS

    use Parrot::Configure::Step::Test;

    $conf = Parrot::Configure::Step::Test->new;
    $conf->include_config_results( $args );

Methods below are inherited from Parrot::Configure:

    $conf->add_steps( 'some_package' );
    $serialized = $conf->pcfreeze();
    $conf->options->set( %options );
    $conf->runsteps();
    $conf->replenish($serialized);

DESCRIPTION

This module is a close simulation of Parrot::Configure to be used for testing of individual configuration steps once Configure.pl has run. Its constructor is structured in the same way as Parrot::Configure::new() -- the Parrot::Configure constructor -- and inherits all Parrot::Configure methods. It adds just one method: Parrot::Configure::Step::Test::include_config_results(). This method populates the data section of the Parrot::Configure object's data structure with the results of Parrot configuration, i.e., %PConfig from Parrot::Config (lib/Parrot/Config.pm).

Rationale

You may skip this section on first reading.

Consider these questions:

1. Why test a Parrot configuration step after that step has already been run by Configure.pl?

2. If Configure.pl has completed successfully, doesn't that, in some sense, prove that the code in the configuration step class was correct? If so, why bother to test it at all?

3. Conversely, wouldn't it make more sense to test a configuration step before that step has been run by Configure.pl?

Parrot developers have debated these questions for years. Between mid-2007 and late-2009, the position reflected in our testing practices was that found in Question 3 above. We included tests of the configuration steps in the set of preconfiguration tests run when you called:

    perl Configure.pl --test=configure

The primary reason for taking this approach was the conviction that the building blocks of the Parrot configuration process ought to be tested before that whole process is executed.

It should be noted that at the point in time when this approach was implemented, there was no testing of the configuration step classes whatsoever. Previously, it was just assumed that if Configure.pl completed successfully, the code in the various configuration step classes did not need more fine-grained testing.

So, some testing of the Parrot configuration steps was clearly an improvement over no testing of those steps.

Nonetheless, there were limits to how well we could apply standard testing practices to the Parrot configuration step classes. The following factors delimited what we could do:

• TK

METHODS

new()

Constructor, structured the same way as that of Parrot::Configure.

See lib/Parrot/Configure.pm.

include_config_results()

Purpose: Populate the Parrot::Configure object with the results of Parrot configuration as recorded in %Parrot::Config::PConfig.

Arguments: One argument: Hash-reference which is the first return value of Parrot::Configure::Options::process_options();

    ($args, $step_list_ref) = process_options( {
        argv => [ ],
        mode => q{configure},
    } );

    $conf = Parrot::Configure::Step::Test->new;

    $conf->include_config_results( $args );

Return Value: None.

AUTHOR

James E Keenan jkeenan@cpan.org

SEE ALSO

Parrot::Configure.

cpanm Rakudo::Star

perl -MCPAN -e shell
install Rakudo::Star