> On Feb 18, 2020, at 2:19 AM, Pierre Smits <pierresm...@apache.org> wrote:
>
> In the build.gradle of the OFBiz repo are some specific tasks defined to do
> some integration testing.
>
> When done locally (in the OFBiz implementation), we execute: ./gradlew
> cleanAll
> loadAll testIntegration
>
> How can I invoke these tasks, and see te result reflect in the report by
> Yetus?
Great question, and now you're getting into where the precommit stuff really
shines. :)
There are two possible ways to do this:
a) Build a new test
b) Modify an existing test (e.g., unit)
To do either of those means digging into the API, but there are plenty of
examples of how do either of these in the various personality files that ship
with Yetus. But a quick rundown:
Option A: Building a new test:
Precommit works by basically looking for functions that tell it what to
do. Adding a new test is a matter of adding new plug-in functions and telling
precommit about the prefix name of the functions that have been defined.
http://yetus.apache.org/documentation/in-progress/precommit-advanced/#plug-ins
has the list of function suffixes, what they do, variables that may be useful,
and general information about how to write a plug-in.
For a simple test:
- calling 'add_test_type <name>' to give the prefix.
- a filefilter function to help determine when this test should
activate (e.g., documentation vs. actual source)
- one or more step functions to actually do the work. For an
integration test, testname_rebuild is the way to go.
There are 3 or 4 of these in the hbase personality.
Option B: Change unit
For something like integrationTests, though, it may be better to just
patch the unit test to be called with different parameters. This is a bit
harder to understand, but is significantly less coding. To do this, you'll
need to create a personality_modules function in your personality file. In
this personality file, you'll basically control the flow of each test that
precommit will trigger. Because of this power, it also means you can change
the parameters that are passed.
Quite a few of the personalities have one of these functions. Some are
very complex (Hadoop) and some are relatively simple (most of them, including
Pig and and Yetus). But they all share something in common: they have some
sort of "if test is foo" statement that does some particular overriding or
adding to a particular test and then pushing the rest back into the build queue.
In this particular case, there would be a check if the test type is
unit and if so, set what the gradlew command line parameters should be by
calling personality_enqueue_module . (parameters). [That . means root of the
source tree. Some build systems break the source up into different modules and
precommit understands that and can short-cut full builds. Alas, gradle doesn't
do that so its work is always at the root of the tree. Someday it'd be great
to understand gradle's source sets so that precommit can shortcut builds for it
too.]
====
Which one is better is a matter of expected outcome and preferences.
Given that unit tests and integrationists are generally independent, I'd
probably lean towards building a new test. But you'll need to probably
experiment and look at what others have done to see which choice is the correct
one for you.
