tryouts
tryouts copied to clipboard
Add diagnostic expectation
Add #=?> for diagnostic expressions that only appear in verbose output on failure.
The ? symbol naturally suggests "questioning" or "investigating" what went wrong, which fits the debugging use case perfectly.
Usage Example
## TEST: Complex user workflow
user = User.create(email: "[email protected]")
subscription = user.subscribe_to_plan("premium")
#=?> user.inspect # Debug: show user state on failure
#=?> subscription.errors.full_messages if subscription.errors.any?
subscription.active?
#=> true
## TEST: Data transformation pipeline
input = { raw_data: complex_structure }
result = DataProcessor.transform(input)
#=?> input.keys # Debug: show input structure
#=?> DataProcessor.last_debug_info # Debug: internal processor state
result[:status]
#=> "success"
Behavior
-
On Success:
#=?>expressions are evaluated but not displayed -
On Failure: All
#=?>expressions from that test case are evaluated and included in the verbose output - Evaluation: Happens in the same context as the test, so has access to all variables
Implementation Considerations
In the existing pattern, this would slot in naturally:
case expectation_line
when /^#=\?>(.+)$/
{ type: :debug_info, expression: $1.strip }
when /^#=>(.+)$/
{ type: :value_equality, expected: $1.strip }
# ... other patterns
end
The debug expressions would be collected alongside regular expectations but only displayed in failure scenarios, helping developers understand test context without cluttering successful runs.
This maintains the philosophy of tests-as-documentation while adding practical debugging capability when things go wrong.