-Megatest is intended to provide the minimum needed resources to make writing a suite of tests 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. A call to megatest can then be made to record the result.
-
-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.
-
-Chicken scheme and a number of eggs are required for building megatest. See the file utils/installall.sh for an automated way to install the dependencies on Linux.
-
+Megatest is intended to provide the minimum needed resources to make writing a suite of tests 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. A call to megatest can then be made to record the result.
+
+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.
+
+Chicken scheme and a number of eggs are required for building megatest. See the file utils/installall.sh for an automated way to install the dependencies on Linux.
+
-This file is used to set environment variables that are run specific. You can simply create an empty file to start.
+This file is used to set environment variables that are run specific. You can simply create an empty file to start.
+
# runconfigs.config
+
+
-
-0.2.2.3 Create the tests directory and your first test
-
+
+
+
+2.2.3 Create the tests directory and your first test
+
The structure should look like this:
-
-../tests
-
-
-├── megatest.config
-
-
-├── runconfigs.config
-
-
-└── tests
-
-
- └── mytest
-
-
- ├── main.sh
-
-
- └── testconfig
-
-
-0.2.2.4 Create the testconfig file for your test
-
+3.1.1 Create your test directory. The directory name will be the name of the test
+
+
+
+
mkdir simpletest
+cd simpletest
+
+
+
+
+
+3.1.2 Create your testconfig file. This file contains various specifications for your test. For our example the test author has chosen to write the test using csh scripting.
+
#!/bin/tcsh -x
+
+# run the cpu1 simulation.
+# The step name is "run_simulation"
+# The commandline being run for this step is "runsim cpu1"
+# The logpro file to validate the output from the run is "runsim.logpro"
+
+$MEGATEST -runstep run_simulation -logpro runsim.logpro "runsim cpu1"
+
+
+
+
+
+You can now run megatest and the created test directory will contain the new files “run_simulation.html” and “run_simulation.log”. If you are using the dashboard you can click on the run and then push the “View log” button to view the log file in firefox.
+
+To run multiple steps simply add them to the main.csh file. Here we add a step to test “cpu2”. The second step that tests cpu2 will only run after the step that tested “cpu1” completes.
+
+
+
+
#!/bin/tcsh -x
+
+# run the cpu1 simulation.
+# The step name is "run_simulation"
+# The commandline being run for this step is "runsim cpu1"
+# The logpro file to validate the output from the run is "runsim.logpro"
+
+$MEGATEST -runstep run_simulation_cpu1 -logpro runsim.logpro "runsim cpu1"
+$MEGATEST -runstep run_simulation_cpu2 -logpro runsim.logpro "runsim cpu2"
+
+
+
+
+
+3.3 Simple Test, Multiple Steps, Some in Parallel
+
+A good way to run steps in parallel within a single test, especially when there are following steps, is to use the Unix Make utility. Writing Makefiles is beyond the scope of this document but here is a minimal example that will run “runsim cpu1” and “runsim cpu2” in parallel. For more information on make try “info make” at the Linux command prompt.
+
+
+
+
# Example Makefile to run two steps in parallel
+
+RTLDIR=/path/to/rtl
+CPUS = cpu1 cpu2
+
+run_simulation_$(CPUS).html : $(RTLDIR)/$(CPUS)
+ $(MEGATEST) -runstep run_simulation_$(CPUS) -logpro runsim.logpro "runsim $(CPUS)
+
#!/bin/tcsh -x
+
+# run the cpu1 and cpu2 simulations in parallel.
+# The -j parameter tells make how many jobs it may run in parallel
+
+make -j 2
+
+
#!/bin/tcsh -x
+
+# run the cpu simulation but now use the environment variable $CPU
+# to select what cpu to run the simulation against
+
+$MEGATEST -runstep run_simulation -logpro runsim.logpro "runsim $CPU"
+
+Sometimes a test depends on the output from a previous test or it may not make sense to run a test is another test does not complete with status “PASS”. In either of these scenarios you can use the “waiton” keyword in your testconfig file to indicate that this test must wait on one or more tests to complete before being launched. In this example there is no point in running the “system” test if the “cpu” and “mem” tests either do not complete or complete but with status “FAIL”.
+
+
+
+
# testconfig for the "system" test
+[setup]
+runscript main.csh
+waiton cpu mem
+