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.
Tests that only require the patch file are run. Note that the repository
is still from the initial checkout!
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:
This step is to wipe the repository clean back to a pristine state such that
the previous cycle will not impact the next cycle.
The patch gets applied.
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.
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.
The basic workflow for many of the sub-items in individual phases are:
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.