Repository navigation
Support schema definitions in the database type #110
Description
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
Activity
alileza commentedon Jun 23, 2020
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
initprocess rather than resource action. For example,snagles commentedon Aug 5, 2020
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.