Architecture

FluentTest is built around a few core components:

1. The expect! macro which captures both values and their textual representation
2. The expect_not! macro which creates negated expectations
3. The Assertion<T> struct which holds the value and provides the fluent API
4. Trait implementations for different types of assertions
5. An event-based system that decouples assertion evaluation from reporting
6. A custom test reporter that enhances the standard output

System Components

FluentTest uses a modular, event-driven architecture:

1. Backend Layer - Core assertion evaluation logic

• Assertion<T> - The main struct that holds values and builds assertions
• Matchers - Trait implementations for different types of assertions
• Modifiers - Support for logical operations (AND, OR, NOT)

2. Config System - Controls the library's behavior

• Config - Configuration options including enabling enhanced output
• Environment variables for controlling behavior without code changes
• Automatic initialization when enhanced output is enabled

3. Event System - Decouples assertion execution from reporting

• AssertionEvent - Events emitted when assertions succeed or fail
• EventEmitter - Responsible for delivering events to registered handlers
• Thread-local handlers for managing assertions across test contexts

4. Frontend Layer - Reporting and user interface

• Reporter - Listens to events and manages test sessions
• ConsoleRenderer - Formats and displays test results

Benefits of the Architecture

This separation of concerns makes the library more maintainable and extensible, allowing for:

• Multiple reporter implementations (console, JSON, HTML, etc.)
• Clean extension points for custom matchers
• Proper isolation between test evaluation and reporting logic
• Flexibility in choosing between standard or enhanced output

Example Flow

When you use expect!(value).to_equal(5):

1. The expect! macro captures both the value and its text representation
2. An Assertion<T> object is created with this information
3. The to_equal method checks if the values match
4. An AssertionStep is created with the result and a sentence
5. If the assertion fails, an event is emitted to the EventEmitter
6. The Reporter receives the event and formats the output
7. The ConsoleRenderer displays the message using the configured format

This event-based architecture allows assertions to be evaluated and reported independently, making the system more flexible and extensible.