test-patch works effectively under several different phases:


This is where test-patch configures and validates the environment.
Some things done in this phase:


Checks done here are fatal.

This acts as a verification of all of the setup parts and is the final
place to short-cut the full test cycle. The most significant built-in
check done here is verifying the patch file is a valid.

Patch File Tests

Tests that only require the patch file are run. Note that the repository
is still from the initial checkout!

Compile Cycle (Branch)

When compilation must be done, we follow these five steps:

The first time this is done is with the pristine checkout. This is called
the "branch compile". For this pass, this is where the 'before' work is
handled. Some things that typically get checked in this phase:

Distribution Clean

This step is to wipe the repository clean back to a pristine state such that
the previous cycle will not impact the next cycle.

Patch Application

The patch gets applied.

Compile Cycle (Patch)

Now that the patch has been applied the steps to compile we outlined in the
compilation (branch) phase are repeated but with the patch applied. This is
where a lot of 'after' checks are performed.

Unit Tests

Since unit tests are generally the slowest part of the precommit process, they
are run last. At this point, all the prerequisites to running them should be
in place and ready to go.


Finally, the results are reported to the screen and, optionally, to JIRA
and/or whatever bug system has been configured.

Test Flow

The basic workflow for many of the sub-items in individual phases are:

  1. print a header, so the end user knows that something is happening
  2. verify if the test is needed. If so, continue on. Otherwise,
    return success and let the next part of the phase execute.
  3. Ask the personality about what modules and what flags should get used
  4. Execute maven (or some other build tool) in the given modules with the
    given flags. Log the output and record the time and result code.
  5. Do any extra work as appropriate (diffs, counts, etc) and either accept
    the status and message given by the maven run or change the vote,
    message, log file, etc, based upon this extra work.
  6. Add the outcome(s) to the report generator

As one can see, the modules list is one of the key inputs into what actually
gets executed. As a result, projects must full flexibility in either adding,
modifying, or even removing modules from the test list. If a personality
removes the entire list of modules, then that test should just be ignored.