view release on metacpan or  search on metacpan

lib/DBD/Informix/TestHarness.pm  view on Meta::CPAN

    my($ssdt, $csdt) = &get_date_as_string($dbh [, $mm [, $dd [, $yyyy]]]);

The first argument is the database handle.
The optional second argument is the month number (1..12).
The optional third argument is the day number (1..31).
The optional fourth argument is the year number (1..9999).
If the date values are omitted, then values from 1930-10-20 are
substituted.
No direct validation is done; if the conversion operations fail,
stmt_fail is called.
The date value is converted to a string by the database server, and the
result returned to the calling function.

Each invocation of C<get_date_as_string> generates one test to be counted.

This function returns an array containing two elements.
The server-side string is returned as element 0, and the client-side
string as element 1.

The server-side string can be enclosed in quotes and will then be
accepted by the server as a valid date in an SQL statement.

The client-side string can be used to define expected values when the
database returns the given date as a DATE value.

Note: the code assumes that the database server supports the '||' string
concatenation operator; this is valid for OnLine 5.00 and above, and
DBD::Informix does not support earlier server versions, so it should
work everywhere that DBD::Informix works.

=head2 Using select_zero_data

The C<select_zero_data> function takes a database handle and the text of
a SELECT statement and ensures that no data is returned.
The test passes unless any data is returned.

    &select_zero_data($dbh, $stmt);

=head2 Using memory_leak_test

This routine takes a reference to a subroutine, and optionally a nap
time in seconds (default 5) and a C<ps> command string (default "ps
-lp", suitable for Solaris 2.x and Solaris 7).

Normally, your test script will simply call this routine and exit.
The remaining code in the test file will implement a test which shows
the memory leak.
You should not connect to the test database before invoking
memory_leak_test.

    use strict;
    use DBD::Informix::TestHarness;
    &memory_leak_test(\&test_subroutine);
    exit;

When it is called, memory_leak_test forks, and the parent process runs
the given subroutine with no arguments.
The subroutine will do the sequence of database operations which show
that there is a memory leak, or that the memory leak is fixed.
The child process checks that the parent is still alive, and runs the
C<ps> command to determine the size of the process.
The output of C<ps> is not parsed, so you have to run the test in a
verbose mode to see whether there is a memory leak or not.

    &memory_leak_test(\&test_subroutine);
    &memory_leak_test(\&test_subroutine, 10, "ps -l | grep");

The C<ps> command string has a process number appended to the end
after a space, and should report the size of the given process.
Note that the last example is not as reliable as requesting the
process status of a specific process number; it will probably show the
grep command and the child Perl process, and maybe random other
processes.

=head2 Using connect_controllably

The C<connect_controllably> function is primarily used by the explicit
C<connect_to_primary>, C<connect_to_secondary>, C<connect_to_tertiary>,
functions, but is also used in its own right.

    $dbh = connect_controllably(1, {PrintError=>1}, \&tertiary_connection);

It takes 3 arguments: a verbose flag (true or false), a reference to the
connection attributes, if any, and a reference to a function such as
C<primary_connection> which returns a database name, username and
password.
It uses these to connect to the database, logs the connection as a
successful test (or dies completely), and returns the database handle.

=head2 Using primary_connection

The primary_connection function returns three values, the database
name, the username and the password for the primary test connection.
This is used internally by the connect_controllably function, and
hence by the connect_to_test_database function.

    my ($dbase, $user, $pass) = &primary_connection();
    my ($dbh) = DBI->connect("dbi:Informix:$dbase", $user, $pass)
                    or die "$DBI::errstr\n";

In looking for the three values, it examines the environment variables
DBD_INFORMIX_DATABASE, DBD_INFORMIX_USERNAME and
DBD_INFORMIX_PASSWORD.
If the database is not determined, it looks at the DBI_DBNAME
environment variable (which is essentially obsolete as far as DBI is
concerned, but which is documented by the esqltest code -- an
alternative was to remove support for DBI_DBNAME from esqltest.ec).
If DBI_DBNAME is not set, then the default database name is 'stores'
with no version suffix.
If the username and password are not set, then empty strings are
returned.

=head2 Using secondary_connection

The secondary_connection function also returns three values, the
database name, the username and the password for the secondary test
connection.
This is used in the multiple connection tests.

    my ($dbase, $user, $pass) = &secondary_connection();