Summary

This PR adds a new OutputFormat utility class to the JUnit Jupiter API that provides enhanced formatting capabilities for assertion failure messages. This addresses issue #3593 by introducing vertical side-by-side collection formatting as a building block for improved assertion diff output.

Changes

• New Class: OutputFormat in org.junit.jupiter.api package
• Key Method: ofVertical(Collection<?> expected, Collection<?> actual) - creates a Supplier that formats two collections side-by-side vertically
• Features:
  • Vertical alignment of expected vs actual collections
  • Proper handling of null collections and empty collections
  • Lazy evaluation through Supplier pattern
  • Clear visual separation with headers and padding

Usage

The OutputFormat.ofVertical() method serves as a building block for improved assertion diff output, making it easier to visually compare collections in test failures.

Related Issue

References #3593

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 NotesAdd OutputFormat utility class for JUnit Jupiter API

This class provides formatting utilities for assertion failure output, specifically:

• ofVertical() static method that formats two collections side-by-side vertically
• Returns Supplier for lazy evaluation of formatted output
• Suitable for use in assertion failure messages when comparing collections
• Includes proper handling of null collections and empty collections
• Follows JUnit Jupiter API patterns and conventions

The vertical format makes it easy to visually compare expected vs actual collections in test failures.

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