Add unit tests for getConfigResources in ModuleDefinitionSet and improve context readability

[he1l0world]

Description

This PR adds unit test coverage for the getConfigResources() method in the ModuleDefinitionSet class to validate context resource logic. This ensures modules are loading the correct Spring context files, including contexts, inherited contexts, and overridden contexts.

To improve readability and avoid confusion, some Spring context XML files were renamed to match their associated modules more intuitively.

Additionally, a small test refactor was made: the instantiation of ModuleBasedContextFactory was moved to the top of the test class as a shared field, since the factory is stateless and does not need to be recreated for each test case

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

Not applicable

How Has This Been Tested?

Added testConfigResources() in ModuleBasedContextFactoryTest.java with assertions for expected Spring resource files.

How did you try to break this feature and the system with this change?

• Provided intentionally incorrect module names to verify fallbacks.

[DaanHoogland]

@he1l0world , your change looks generally good to but one remarks:
You have a base test method but then call it from the same test method several times, these seem different test cases to me.
Does it make sense to split them?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 16.60%. Comparing base (f8c4121) to head (390ac7b).

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #11042   +/-   ##
=========================================
  Coverage     16.60%   16.60%           
- Complexity    13925    13926    +1     
=========================================
  Files          5730     5730           
  Lines        508254   508254           
  Branches      61789    61789           
=========================================
+ Hits          84387    84390    +3     
+ Misses       414431   414430    -1     
+ Partials       9436     9434    -2     

Flag	Coverage Δ
uitests	3.93% <ø> (ø)
unittests	17.49% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[he1l0world]

@he1l0world , your change looks generally good to but one remarks: You have a base test method but then call it from the same test method several times, these seem different test cases to me. Does it make sense to split them?

Yes, it makes sense to me. I will update them

[DaanHoogland]

clgtm

[DaanHoogland]

@blueorangutan package

[blueorangutan]

@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13820