Setting up an integrated test is done by (do >ctnewpackage -h
for a list of flags)
>ctnewpkg -ui mypackagectb
from the release directory. This will, among others, create a
mypackagectb/test
directory.
We now have two distinct cases: the package to be tested is a framework package, or it is not. In the latter case, the best thing to do is probably to embed it in a framework shell for testing. One way to do this is described in episode 6.
If it is a framework package, it's rather easy. First copy
all the required .rcp files to mypackagectb/test,
then
>cp mypackagectb/src/LIBRARIES mypackagectb/test/.
>cd mypackagectb/test
>xemacs LIBRARIES &
Add mypackagectb to the top of the list.
>xemacs testxxx.cpp &
This can in principle be a dummy file, but generally the datafile that
will be read contains more Chunks than those we use in the package.
To make sure framework recognizes them, add
#include "d0_mcpp/MCKineChunk_ref.hpp"
etc. to the file (all the Chunks in the input file that aren't
used by the package).
Next, edit ITESTS:
>xemacs ITESTS &
and add testxxx to it (or whatever you called the .cpp file
you just created - without the .cpp extension).
Now OBJECTS (this file has not necessarily been created by ctnewpkg):
>xemacs OBJECTS &
Here you have to list all the object files that have to go on the link
line: the registration file (see ../src/OBJECT_COMPONENTS), and
framework
stuff you use like framework, ReadEvent, ...
Last but not least, running the integrated test should require the presence
of other files (.rcp,...), so
>cp $BFDIST/releases/$BFCURRENT/ctest/run_integrated_test.sh testxxx.sh
and edit appropriately (see phase1).
Now go back to the release directory and run
>gmake mypackagectb.test
This will run the integrated test - i.e. run on the input file you
specified, go through processEvent for each event, produce ntuples
etc. All the results go in tmp/$BFARCH/mypackagectb/itest/testxxx.dir
.