…
This directory is filled with tools to help test tinderbox.
Unfortunatly I have not had time to make an automated test suite so
you will need to run the tests by hand and conduct visual inspections
and hyperlink exploration.
The tests are run out of the build (not install directory) and I
usually make a special TinderConfig which puts the HTML, GZLOG and
DATA into the same directory which is a subdir of
/tmp/tinderbox2. This config file is placed in the ./build/local_conf
I can then run my tests on the same machine which I package up my
production version and the two are separate and use different config
files.
A) DISPLAY TESTS
----------------
There are several gen* test scripts which can be used to simulate a
busy tinderbox system. These are used for load testing and for
general configuration testing.
1) $prefix/build/test/genbuilds: generates a days worth of random
build information as if the build machines had sent the data. There
are not random logs generated for this test so all the 'L' links will
point to nothing useful. The output looks as if the processmail_build
system has been posting updates of mail received.
2) $prefix/build/test/gennotes: generates a days worth of random
notice information as if the developers have been posting notices.
3) $prefix/build/test/genbugs: generates a days worth of random bug
ticket information as if the processmail_bug system has been posting
updates of mail received.
The makefile will automatically run all the gen* tests if you run
'make gen_test'.
Here are some hints when running the gen* programs.
A) You need to have the SAME project names src/lib/TreeData.pm in the
keys of %VC_TREE as are generated by the gen* test programs currently
('Project_A', 'Project_B', 'Project_C').
B) You should fill in the other %VC_TREE data to get the CVS
information from YOUR project so that you can test the VC_CVS portion
of the code at the same time.
Here is an example of TreeData which points at a CVS repository, use
your own data:
root => ':pserver:kestes@cvs.mozilla.org:/mozilla/seamonkey',
module => 'SeaMonkeyAll',
branch => 'main',
C) If you run 'Make gen_test' the tests will be run for you.
D) You must run the gen programs only once to generate data. If you
need to run the test again, you must remove all the data directories
and start with a clean slate.
E) After generating the data run
$prefix/build/bin/tinder.cgi --daemon-mode
to generate the HTML pages based on this data. Examine the output with
a brower and ensure that it is what you want.
F) Tinderbox will write a lock file while it is running. This lock
file prevents two instances of tinderbox from running at the same time
and corrupting the database. If the lock file is left behind from a
previous run (if the run was killed) it will prevent tinderbox from
processing any more data and the lock file must be removed by hand.
B) MAIL TESTS
-------------
There are sample mail files so that you can test the processmail
programs. Not only is this helpful for developers who need to see if
the processmail program works on a particular log file but it is
helpful to administrators who whish to test the configuration of the
full data path (from mail delivery through to a link on the web page).
The test for the build mail system will generate two log files (in
compressed HTML with their errors hightlighted) and an update file
(this is the file which tells the main tinderbox server all about the
new updates and provides the information about how to make a HREF link
to the compressed logs). I suggest using:
$TinderConfig::PersistenceImpl = 'Persistence::Dumper'
so that you can see the results of this test in a pager.
1) Run the simple test like this:
$prefix/build/bin/processmail --skip-check --force-time ./build/test/logsample.html
This log file contains only errors as a reference for testing the
error patterns.
$prefix/build/bin/processmail --skip-check --force-time ./build/test/error.tst
2) You can then run
$prefix/build/bin/tinder.cgi --daemon-mode
to generate the web pages and ensure that there are working links to
the log files.
3) This is a similar test for the bug tracking system.
The test for the bugtracking system will generate an update file
(this is the file which tells the main tinderbox server all about the
new updates and provides the information about how to make a HREF link
to the compressed logs). I suggest using:
$prefix/build/bin/processmail_bugs --skip-check --force-time ./test/bugzilla.mail
4) You can then run
$prefix/build/bin/tinder.cgi --daemon-mode
to generate the web pages and ensure that there are working links
which popup information about the processed bug.
When this work to your satisfaction you can remove the test HTML and
DATA directories. Other tests are independent of this one.
C) Regression Tests:
--------------------
These tests are mostly of interest to developers.
1) All hyperlinks should be genereated via the Link function not hard
coded in the source with a '<a href=\"status.html\">status</a>'.
Check this by running 'make link_test'. This test fails if there is
any output
2) run util.tst this should exit without comment and with exit
code (shell variable $?) 0.
3) The makefile will check if the code compiles. There are two
makefile targets for this: compile_bin_code, compile_all_code.
4) If you run "make popup_test" a new HTML directory is created called
popup and this will contain sample files demonstrating each popup
library. Additionally some regression tests are performed on the HTML
processing code.
5) run 'make cvskeyword_test' to see if all the source files have cvs
keywords in them. It greatly helps in tracking problems down on
servers when the code tells you what version it came from.
6) The file vcdisplay.tst is used to test that the implemenations of
VCDisplay produce output which could reasonably be expected to work
when passed to bonsai. The output must be examined manually.