Serge Huber created UNOMI-944:
---------------------------------
Summary: Add integration test developer tooling for run archival,
cross-run comparison, and live Karaf inspection
Key: UNOMI-944
URL: https://issues.apache.org/jira/browse/UNOMI-944
Project: Apache Unomi
Issue Type: Sub-task
Components: unomi(-core)
Affects Versions: unomi-3.1.0
Reporter: Serge Huber
Fix For: unomi-3.1.0
When integration tests fail, developers spend a lot of time on friction that
has nothing to do with the actual bug.
*The problems today*
* Every rebuild wipes {{itests/target/}} — taking server logs, test reports,
and configuration with it. If you didn't look before rebuilding, the evidence
is gone.
* Deciding whether a failure is a real regression or just a flaky test means
manually running the suite multiple times and keeping mental notes of which
tests failed in which run. There is no structured way to compare runs.
* The Karaf server is created with a random UUID directory name each run.
Finding the log file or attaching a debugger means hunting for that path every
time.
* When a developer reports a failure, there is no record of which search
engine, heap sizes, or build flags were used. Reproducing it requires guessing.
*What this ticket adds*
A set of opt-in shell scripts in {{itests/}} that cover the full lifecycle of
an IT run:
* *{{archive-it-run.sh}}* — captures a structured snapshot of test results,
server logs, engine configuration, and build options after a run, before the
next build wipes them. Also generates a filtered view of the server log that
strips out intentional noise (errors that tests deliberately trigger) so only
unexpected failures stand out.
* *{{compare-it-runs.sh}}* — diffs two or more snapshots and classifies each
test as consistently failing, consistently passing, or flaky.
* *{{kt.sh}}* — a small utility that auto-locates the current Karaf test
instance and provides {{{}log{}}}, {{{}tail{}}}, {{{}grep{}}}, {{{}start{}}},
{{{}stop{}}}, and {{debug}} commands without needing to find the UUID path
manually.
* *Build trace in {{build.sh}}* — records the exact Maven options, search
engine, heap sizes, and flags for every IT run so failures can be reproduced
precisely.
* *{{itests/README.md}}* — updated to document all tooling in one place.
*Who is affected*
Developers running or debugging integration tests locally. This has no impact
on production code, API behaviour, or CI pipelines. All tooling is opt-in and
runs outside the normal build path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
