Link: https://github.com/aliamerj/volcapi

I kept running into a situation where my OpenAPI spec and my test collection described the same endpoints but slowly drifted apart. Someone updates the spec, forgets the tests. Someone fixes a test, doesn't touch the spec. The usual.

I built VolcAPI to collapse this into one file. You add a v-functional-test extension to your OpenAPI spec and define test scenarios in the same file or different files. The spec becomes executable.

paths:
  /auth/login:
    post:
      summary: User login
      v-functional-test:
        scenarios: ["valid_login", "wrong_password"]
 
scenarios:
  valid_login:
    headers:
      Content-Type: application/json
    request:
      email: user@example.com
      password: correct
    response:
      status: 200
      body:
        contains: ["token"]
 
  wrong_password:
    request:
      email: user@example.com
      password: wrong
    response:
      status: 401

volcapi run volcapi_local.yml -o openapi.yml

It's a static Go binary — no runtime, no dependencies. The immediate goal is CI integration: JUnit XML output and a working GitHub Actions example are in progress.

This is alpha. GET/POST/PUT/DELETE work. Response validation works. CI output formats are next.

Repo: https://github.com/aliamerj/volcapi

Curious whether the "spec as test suite" model makes sense to people here, or whether you'd keep tests separate from the spec on principle. I've gone back and forth on this design decision and haven't fully settled it.

I don’t think this will become the way to do things, but I would imagine there are plenty of cases where this type of declarative management makes sense. Looks cool!