Blueprint changed by John H. Embretsen:
Whiteboard set to:
Current proposal:
----------------------------
Utilize the RQG's Properties.pm module. WIth this, it is easy to read
options from both the command-line and a separate file, and to merge
these automatically.
Examples which use this facility already are utilities such as util
/simplify-mysqltest.pl, util/bughunt.pl, gentest.pl.
The file containing the test configuration defines an anonymous Perl
hash, with possible nested hashes for special groups of options.
Example format:
---------------------------
example_test.cfg (extension either ".cfg" or ".test"):
-----------------------------
# Comments here, for describing the test, why settings are as they are, etc.
#
# We may introduce options for providing test descriptions and such as well,
# so that it may be passed along to reporting systems.
#
# Some variables may have default values set by the RQG framework or wrapper
scripts.
# Full set and explanation of options to be provided later.
{
name => 'rqg_example_test',
category => 'runtime',
candidate => 'true',
grammar => 'conf/example.yy',
threads => 10,
mysqld => {
'log-output' => 'file'
}
}
-----------------------------
Here, options for the wrapper script (interpreter) or the RQG framework itself
are defined on the top level.
Options for external products such as the database server under test are
defined as a nested structure (hash). In this example one option is set for
mysqld, the MySQL Server.
-----------------------------
We will introduce a script (perhaps later even a module) that is able to
kick-start a test based on options taken from the configuration file
and/or command-line options.
Command-line options will be able to override options from file.
Other considered formats:
- XML. Universal and pretty standard, well-supported format. However, parsing
requires non-core perl modules with possibly known issues on some platforms.
- JSON (JavaScript Object Notation). Although standard and with relatively
good Perl support, there are no apparent advantages compared to the other
suggested format. Somewhat increased complexity that is not needed at this
time. Requires non-core Perl modules.
Since we, for now, assume that we will stick to perl within the RQG, and
that we may relatively easily create tools for converting tests from
perl data structures to other formats if necessary, perl data structures
seem like the best choice.
---------------------------------------------------------------------------
--
Introduce test definitions in separate files
https://blueprints.launchpad.net/randgen/+spec/test-definitions
_______________________________________________
Mailing list: https://launchpad.net/~randgen
Post to : [email protected]
Unsubscribe : https://launchpad.net/~randgen
More help : https://help.launchpad.net/ListHelp
