Description
When testing APIs, it's often necessary to validate that response values match certain patterns rather than exact values. Currently, Tomato only supports exact value matching for JSON assertions.
Use Case
Scenario: Create provider returns valid UUID
When "api" sends "POST" to "/api/providers" with json:
"""
{ "provider_name": "Test Provider" }
"""
Then "api" response status is "201"
# Want to verify ID is a valid UUID format, not a specific value
And "api" response json "id" matches pattern "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
And "api" response json "createdAt" matches pattern "\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}"
Current Workaround
Can only check if a field exists, but not its format:
Then "api" response json "id" exists
This doesn't validate that the ID is actually a valid UUID.
Proposed Step Definitions
# Regex pattern matching
And "api" response json "field" matches pattern "REGEX"
# Common built-in patterns
And "api" response json "id" is uuid
And "api" response json "email" is email
And "api" response json "createdAt" is iso-timestamp
# Numeric comparisons
And "api" response json "count" is greater than "0"
And "api" response json "price" is between "10" and "100"
# String length
And "api" response json "name" has length between "1" and "255"
Benefits
- Validate data format without knowing exact values
- Test generated fields (IDs, timestamps, tokens)
- More robust tests that don't break when data changes
- Catch API bugs that return malformed data
Environment
- Tomato version: latest
- OS: macOS
Description
When testing APIs, it's often necessary to validate that response values match certain patterns rather than exact values. Currently, Tomato only supports exact value matching for JSON assertions.
Use Case
Current Workaround
Can only check if a field exists, but not its format:
This doesn't validate that the ID is actually a valid UUID.
Proposed Step Definitions
Benefits
Environment