Add tests for Kotlin inline value class

[Ogu1208]

Resolves: #5081

Overview

This Draft PR is based on @marcphilipp’s proof-of-concept branch marc/5081-kotlin-value-class-support, which introduces initial support for Kotlin inline value class parameter resolution.

Currently, the POC supports only kotlin.Result parameters in parameterized tests. This PR extends the existing test coverage to highlight the current behavior and limitations, and prepares the ground for supporting arbitrary Kotlin @JvmInline value classes in future updates.

Changes

• Added new test classes under org.junit.jupiter.api.kotlin:
  • MultipleInlineValueClassTest: covers multiple inline and normal parameters in one test.
  • CustomInlineValueClassTest: covers user-defined inline classes (UserId, Email).
  • NullableInlineValueClassTest: covers nullable inline and Result parameters.
• Annotated CustomInlineValueClassTest with @Disabled, since current POC supports only kotlin.Result.
• Intentionally left failing tests in place to demonstrate existing gaps.

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• [ ] There are no TODOs left in the code
• [ ] Method preconditions are checked and documented in the method's Javadoc
• [ ] Coding conventions (e.g. for logging) have been followed
• [ ] Change is covered by automated tests including corner cases, errors, and exception handling
• [ ] Public API has Javadoc and @API annotations
• [ ] Change is documented in the User Guide and Release Notes

[Ogu1208]

Hi @marcphilipp 👋

Sorry for the delay — this is actually my first attempt at contributing to an open-source project like JUnit,
so I wanted to take a bit of extra time to make sure I understood everything properly before opening this draft.

As discussed in #5081, I’ve based this Draft PR on the marc/5081-kotlin-value-class-support POC branch
and added extended test coverage for Kotlin inline value class parameter resolution.

There are still a few points I’d like to clarify, since I might have misunderstood parts of the earlier discussion:

1. Is the intention for this issue to eventually cover arbitrary @JvmInline classes beyond kotlin.Result?
   (From your earlier comments, it seems like @TWiStErRob might be leading that implementation effort.)
2. For this PR, is it most helpful if I focus solely on test coverage and verification for now,
   or would it be okay to start exploring how kotlin-reflect could generalize the current handling?

I’m happy to adjust the scope based on your guidance.

[Ogu1208]

@marcphilipp 👋 Just wanted to kindly follow up on this — could you please take a look when you have a chance?

[testlens-app[bot]]

✅ All tests passed ✅

⚠️ TestLens detected flakiness ⚠️

Test Summary

Check	Task	Test	Runs
CI / Linux	:jupiter-tests:test	@Timeout > separate thread > one test is stuck "forever" in separate thread and other tests in same thread not	🚫 ⚠️

🏷️ Commit: 25feab980159fa8a65585c542bc895640d3eb08e ▶️ Tests: 45600 executed ⚪️ Checks: 15/15 completed

Test Failure

@Timeout > separate thread > one test is stuck "forever" in separate thread and other tests in same thread not (:jupiter-tests:test in Linux)

org.opentest4j.AssertionFailedError: 
expected: SUCCESSFUL
 but was: FAILED
	at org.junit.jupiter.engine.extension.TimeoutExtensionTests$SeparateThread.oneThreadStuckForeverAndOtherTestsInSameThread(TimeoutExtensionTests.java:466)

---

Learn more about TestLens at testlens.app.

[marcphilipp]

Please add an entry to the 6.1.0-M2 release notes.

@Ogu1208 Do you have time to address this or should we take over?

[Ogu1208]

@marcphilipp

Thank you for the feedback. I've added the release note entry.

Please let me know if any adjustments are needed. Apologies for the delay.