tomato

tomato copied to clipboard

Is your feature request related to a problem? Please describe. Define database schema using Gherkin clauses.

Describe the solution you'd like Support for sql schema definitions inside the feature test files.

Describe alternatives you've considered Migrations as part of the database setup/teardown process. Support inside the database resource

This sounds like a good idea, that we'd reduce the database set-up complexity before running tomato. But I have a few questions regarding this approach

• Does this means all tables will be dropped on each before scenario is executed? if so, that means we need to always specify all table schema on each Feature we wrote, and it will simply a breaking change for our current version of tomato, since they didn't handle the schema specification

• Is there a use case that we have different schema on each Scenario/Feature?

• If there isn't, maybe we could have this feature as part of init process rather than resource action. For example,

resources:
     - name: tomato-mysql
       type: mysql
       params:
         datasource: mysql://user:pass@tcp(localhost:3306)/hello
         initdb: some-path/dbschema.sql

I think you raise some good points, I'm not sure if it would make sense in the Gherkin clauses considering the breaking changes. I like the thought of a general init stage for the resource in this case, I could see this even expanding for other resources (e.g wiremock) that have a similar set of procedures for the initializing process.