[BUILD-412] Consider lifting 'forked-test-execution' profile to parent pom Created: 06/Nov/20  Updated: 27/Oct/22

Status: Accepted
Project: Build
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Epic Link: Basic JUnit 5
Team: Foundation

 Description   

Surefire's forked mode execution is a nice and battle-tested way of parallelising the JUnit test runs. Unlike parallelisation approaches in JUnit 5 in forked mode several JVMs distribute test suite classes among each other and run them in separate processes.

Benefits:

  • This approach is almost the same as running all the tests sequentially: as far as each test is concerned - it is executed in JVM isolation, preventing issues with static resources, concurrency etc
  • We already successfully use this approach in CE/DX-core bundles to execute UI tests
  • Is enabled on Surefire configuration level. Tests do not need to account for anything extra (except for the caveats listed below).

Caveats:

  • workingDirectory configuration becomes somewhat tricky. Typically the tests would be executed in the root context of the project, being able to access resources from well-known paths at src/test/... as well as writing at them. With forked mode each fork ideally has its own working directory (Surefire's workingDirectory config parameterised against ${surefire.forkNumber}). This complicates the file system access to the files (constructing their paths to be precise) and screws up tests that rely on FS such as e.g. MVH. RepositoryTests are the worst affected since they deploy repos directly in the working dirs and several forks may mess up each others repositories. (One way to circumvent this is to account for the forked mode in the Repo test case and set the magnolia.repositories.home accordingly)

Motivation:

All in all this has a good potential to speed up our builds: with only several unresolved failures the core test run took less than 2 minutes (on 8 core machine).

Suggestion:

  • timebox this with a couple of work days effort
  • see if we can non-intrusively enable forked mode for core and UI (with the FS locations parameterisation mentioned above)

Generated at Sun Feb 11 23:41:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.