Tasty! A TOML-driven CLI for Testing APIs

Tasty is a command-line tool that runs API tests defined and grouped in TOML files.

I’m building it as I migrate my bash scripts for API testing over to this little binary.

Here’s an example of what it looks like:

Running tests from "user_signup.toml"
  accept_valid_signup ... failed
    Status code mismatch:
    Expected: 200
    Returned: 400
    Payload mismatch:
    Expected: 
      {
        "status": "ok"
      }
    Returned: 
      {
        "reason": "email_already_registered",
        "status": "failed"
      }
  reject_duplicate_email ... ok (313ms)
  reject_malformed_email ... ok (1ms)
  reject_missing_password ... ok (1ms)
  reject_password_minimum_requirements ... ok (1ms)

Test Summary:
  Total tests: 6
  Passed: 4
  Failed: 2
  Skipped: 0
  Total duration: 768ms

Some tests failed

# Writing Tests

Tests are defined in and grouped by TOML files. If you have a TOML file named user_signup.toml, all the tests in side that file can be invoked with Tasty by passing it as a command-line argument.

Each test file can contain multiple test cases. Here’s an example of a file with a single test case:

# user_signup.toml

[accept_valid_signup]
method = "POST"
route = "auth/signup"
payload = { email = "[email protected]", password = "This is a Valid Password!@t%" }
expect_http_status = 200
expect_response_includes = { status = "ok" }

# Test File Syntax

Test files have the following properties that MUST be present in each table:

• name (Optional) The table key is the name of the test in the output report, but you can use this field if you’d like your table keys to be different from your test names. You might want this if you prefer the table keys in your TOML files to be organized differently than by the name of each test.
• method The HTTP method to be used in the request
• route The route to send the request to, not including the base URL
• payload A TOML table that includes the request data
• expect_http_status The integer HTTP response code that indicates a passing test
• expect_response_includes (Optional) One or more properties that MUST be present in the response payload

# Participating & Contributing

Contributions are welcome and encouraged. Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.

# Future Improvements

While tasty is already useful for my purposes in its current form, I am open to backwards-compatible enhancements that include (but are not limited to):

• passing response values (like a a JWT) from one test to another
• optional json output of test results
• parallel test execution
• test dependencies and ordering
• response schema validation
• custom test reporters
• environment variable substitution
• request/response logging