[Discussion] Revisiting Multi-Line String Arguments: A Persistent Need for Readability and Consistency #2777
Description
Introduction
This issue aims to consolidate and build upon the long-standing discussion around supporting multi-line string arguments in Gauge specs. This feature has been requested by users for years, as shown in these previous issues:
Labels: enhancement, discussion, help wanted
#175 (2015 - Closed)
#1240 (2018 - Closed)
#2756 (2025 - Closed)
The consistent reason for closing these issues has been the desire to maintain spec readability. While this is a noble goal, the lack of this feature is now a significant source of reduced readability and consistency in the real world.
The Core Inconsistency
The most compelling reason to reconsider this is an architectural inconsistency within Gauge itself:
Gauge already supports large, multi-line data structures natively via Tables. A spec can have a table with dozens of rows and columns, and this is considered a powerful feature, not a readability failure.
It is inconsistent to allow this:
|id|name|address |
|--|----|--------------------------------------|
|1 |John|123 Main St, Anytown, USA, 12345 |
|2 |Jane|456 Oak Ave, Somewhere, Canada, A1B 2C|
...but not allow this conceptually simpler case:
* Step with the text
"
This is line 1
This is line 2
This is line 3
"
If the framework can handle the complexity and visual weight of tables, handling a multi-line string argument is a smaller, more contained problem. The current stance forces users to use tables for non-tabular data, which is the true readability anti-pattern.
The Pain of Current Workarounds
As evidenced by the repeated requests in #1240 and #2756, users are forced into suboptimal patterns:
- Semantically Incorrect Tables: Using a single-column table as a list, which adds visual noise.
- Hidden Test Data: Concatenating strings in code, which hides critical test data from the specification and makes tests harder to debug and understand.
A Proposed Path Forward
The conversation has stalled on "readability," but it should advance to "how can we implement this without harming readability?"
Modern tools use clear syntax like triple-quotes to make multi-line strings first-class citizens without sacrificing clarity:
Proposal:
* Step that parses the following JSON
"""
{
"name": "Gauge",
"type": "Testing Framework"
}
"""
This syntax is clean, visually scoped, and a common pattern developers already understand from languages like Python, YAML, and JavaScript.
Call to Action
The volume and persistence of these requests indicate this is a genuine usability gap. This issue is not a duplicate but a request to:
- Re-open the discussion with a focus on the inconsistency with tables.
- Re-evaluate the cost/benefit based on years of user feedback.
- Define an acceptable syntax if the core team's concerns about implementation can be addressed.
I have reviewed the past issues and am willing to contribute development effort towards a solution that aligns with the team's guidelines. Perhaps we can use this thread to agree on a syntax and approach.