Preface
-This book is organised as three sub-books; getting started, writing tests and reference.
Why Megatest?
-The Megatest project was started for two reasons, the first was an -immediate and pressing need for a generalized tool to manage a suite -of regression tests and the second was the fact that the author had -written or maintained several such tools at different companies over -the years and it seemed a good thing to have a single open source -tool, flexible enough to meet the needs of any team doing continuous -integrating and or running a complex suite of tests for release -qualification.
Megatest Design Philosophy
-Megatest is intended to provide the minimum needed resources to make -writing a suite of tests and tasks for implementing continuous build -for software, design engineering or process control (via owlfs for -example) without being specialized for any specific problem -space. Megatest in of itself does not know what constitutes a PASS or -FAIL of a test. In most cases megatest is best used in conjunction -with logpro or a similar tool to parse, analyze and decide on the test -outcome.
Megatest Architecture
-All data to specify the tests and configure the system is stored in -plain text files. All system state is stored in an sqlite3 -database. Tests are launched using the launching system available for -the distributed compute platform in use. A template script is provided -which can launch jobs on local and remote Linux hosts. Currently -megatest uses the network filesystem to call home to your master -sqlite3 database.
Road Map
-Note: This road-map is tentative and subject to change without notice.
ww32
--
-
-
-
-Rerun step and or subsequent steps from gui -
-
- -
-
-Refresh test area files from gui -
-
- -
-
-Clean and re-run button -
-
- -
-
-Clean up STATE and STATUS handling. -
---
-
-
-
-Dashboard and Test control panel are reverse order - choose and fix -
-
- -
-
-Move seldom used states and status to drop down selector -
-
-
- -
-
-
-
-Access test control panel when clicking on Run Summary tests -
-
- -
-
-Feature: -generate-index-tree -
-
- -
-
-Change specifing of state and status to use STATE1/STATUS1,STATE2/STATUS2 -
-
-
ww33
--
-
-
-
-http api available for use with Perl, Ruby etc. scripts -
-
- -
-
-megatest.config setup entries for: -
---
-
-
-
-run launching (e.g. /bin/sh %CMD% > /dev/null) -
-
- -
-
-browser "konqueror %FNAME% -
-
-
- -
-
ww34
--
-
-
-
-Mark dependent tests for clean/rerun -rerun-downstream -
-
- -
-
-On run start check for defunct tests in RUNNING, LAUNCHED or REMOTEHOSTSTART and correct or notify -
-
- -
-
-Fix: refresh of gui sometimes fails on last item (race condition?) -
-
-
ww35
--
-
-
-
-refdb: Add export of csv, json and sexp -
-
- -
-
-Convert to using call-with-environment-variables where possible. Should allow handling of parallel runs in same process. -
-
- -
-
-Re-work text interface wizards. Several bugs on record. Possibly convert to gui based. -
-
- -
-
-Add to testconfig requirements section; launchlimiter scriptname, calls scriptname to check if ok to launch test -
-
- -
-
-Refactor Run Summary view, currently very clumsy -
-
- -
-
-Add option to show steps in Run Summary view -
-
-
ww36
--
-
-
-
-Refactor guis for resizeablity -
-
- -
-
-Add filters to Run Summary view and Run Control view -
-
- -
-
-Add to megatest.config or testconfig; rerunok STATE/STATUS,STATE/STATUS… -
-
- -
-
-Launch gates for diskspace; /path/one>1G,/path/two>200M,/tmp>5G,#{scheme toppath}>1G -
-
-
Bin List
--
-
-
-
-Quality improvements -
---
-
-
-
-Server stutters occasionally -
-
- -
-
-Large number of items or tests still has some issues. -
-
- -
-
-Code refactoring -
-
- -
-
-Replace remote process with true API using json (supports Web app also) -
-
-
- -
-
-
-
-Streamline the gui -
---
-
-
-
-Everything resizable -
-
- -
-
-Less clutter -
-
- -
-
-Tool tips -
-
- -
-
-Filters on Run Summary, Summary and Run Control panel -
-
- -
-
-Built in log viewer (partially implemented) -
-
- -
-
-Refactor the test control panel -
-
-
- -
-
-
-
-Help and documentation -
---
-
-
-
-Complete the user manual (I’ve been working on this lately). -
-
- -
-
-Online help in the gui -
-
-
- -
-
-
-
-Streamlined install -
---
-
-
-
-Deployed version (download a location independent ready to run binary bundle) -
-
- -
-
-Install Makefile (in progress, needed for Mike to install on VMs) -
-
- -
-
-Added option to compile IUP (needed for VMs) -
-
-
- -
-
-
-
-Server side run launching -
-
- -
-
-Support for re-running, cleaning etc. of individual steps (ezsteps makes this very easy to implement). -
-
- -
-
-Launch process needs built in daemonizing (easy to do, just need to test it thoroughly). -
-
- -
-
-Wizards for creating tests, regression areas (current ones are text only and limited). -
-
- -
-
-Fully functional built in web service (currently you can browse runs but it is very simplistic). -
-
- -
-
-Wildcards in runconfigs: e.g. [p1271/9/%/%] -
-
- -
-
-Gui panels for editing megatest.config and runconfigs.config -
-
- -
-
-Fully isolated tests (no use of NFS to see regression area files) -
-
- -
-
-Windows version -
-
-
Getting Started
-How to install Megatest and set it up for running your regressions and continuous integration process.
Installation
-Dependencies
-Chicken scheme and a number of "eggs" are required for building -Megatest. See the script installall.sch in the utils directory of the -distribution for a mostly automated way to install everything needed -for building Megatest on Linux.
[An example footnote.]
And now for something completely different: monkeys, lions and -tigers (Bengal and Siberian) using the alternative syntax index -entries. - - - -Note that multi-entry terms generate separate index entries.
Here are a couple of image examples: an - - -example inline image followed by an example block image:
Followed by an example table:
Option | -Description | -
---|---|
-a USER GROUP |
-Add USER to GROUP. |
-
-R GROUP |
-Disables access to GROUP. |
-
Lorum ipum…
Sub-section with Anchor
-Sub-section at level 2.
Chapter Sub-section
-Sub-section at level 3.
Chapter Sub-section
-Sub-section at level 4.
This is the maximum sub-section depth supported by the distributed
-AsciiDoc configuration.
-
[A second example footnote.]
The Second Chapter
-An example link to anchor at start of the first sub-section.
An example link to a bibliography entry [taoup].
Writing Tests
-The First Chapter of the Second Part
-Chapters grouped into book parts are at level 1 and can contain -sub-sections.
Reference
-The First Chapter of the Second Part
-Chapters grouped into book parts are at level 1 and can contain -sub-sections.
The testconfig File
-Setup section
-Header
-[setup]-
The runscript method is a brute force way to run scripts where the -user is responsible for setting STATE and STATUS
runscript main.csh-
Requirements section
-Header
-[requirements]-
Wait on Other Tests
-# A normal waiton waits for the prior tests to be COMPLETED -# and PASS, CHECK or WAIVED -waiton test1 test2-
Mode
-The default (i.e. if mode is not specified) is normal. All pre-dependent tests -must be COMPLETED and PASS, CHECK or WAIVED before the test will start
mode normal-
The toplevel mode requires only that the prior tests are COMPLETED.
mode toplevel-
A item based waiton will start items in a test when the -same-named item is COMPLETED and PASS, CHECK or WAIVED -in the prior test
mode itemmatch-
# With a toplevel test you may wish to generate your list -# of tests to run dynamically -# -# waiton #{shell get-valid-tests-to-run.sh}-
Run time limit
-runtimelim 1h 2m 3s # this will automatically kill the test if it runs for more than 1h 2m and 3s-
Skip
-Header
-[skip]-
Skip on Still-running Tests
-# NB// If the prevrunning line exists with *any* value the test will -# automatically SKIP if the same-named test is currently RUNNING - -prevrunning x-
Skip if a File Exists
-fileexists /path/to/a/file # skip if /path/to/a/file exists-
Controlled waiver propagation
-If test is FAIL and previous test in run with same MT_TARGET is WAIVED then apply the following rules from the testconfig: -If a waiver check is specified in the testconfig apply the check and if it passes then set this FAIL to WAIVED
Waiver check has two parts, 1) a list of waiver, rulename, filepatterns and 2) the rulename script spec (note that "diff" and "logpro" are predefined)
###### EXAMPLE FROM testconfig ######### -# matching file(s) will be diff'd with previous run and logpro applied -# if PASS or WARN result from logpro then WAIVER state is set -# -[waivers] -# logpro_file rulename input_glob -waiver_1 logpro lookittmp.log - -[waiver_rules] - -# This builtin rule is the default if there is no <waivername>.logpro file -# diff diff %file1% %file2% - -# This builtin rule is applied if a <waivername>.logpro file exists -# logpro diff %file1% %file2% | logpro %waivername%.logpro %waivername%.html-
Ezsteps
-To transfer the environment to the next step you can do the following:
$MT_MEGATEST -env2file .ezsteps/${stepname}-
Appendix A: Example Appendix
-One or more optional appendixes go here at section level zero.
Appendix Sub-section
-
- Note
- |
-Preface and appendix subsections start out of sequence at level -2 (level 1 is skipped). This only applies to multi-part book -documents. | -
Example Bibliography
-The bibliography list is a style of AsciiDoc bulleted list.
Example Glossary
-Glossaries are optional. Glossaries entries are an example of a style -of AsciiDoc labeled lists.
-
-
- -A glossary term - -
-
-
- The corresponding (indented) definition. -
-
- - -A second glossary term - -
-
-
- The corresponding (indented) definition. -
-
-
Example Colophon
-Text at the end of a book describing facts about its production.