Refactor parser tests with common feature structure

[tnyo43]

Task description

Make tests easier to implement and maintain by unifying their structure

Background

Currently, all parser tests use a shared output generator called createParserTestCases. This generator ensures that each parser produces the same result with appropriate input. It helps verify that all parsers meet a consistent baseline.

However, the assumption that all parsers will produce the same output for some appropriate inputs doesn’t always hold true. For example, the tbls parser may return output which defines relationships even when there are no corresponding foreign key constraints, while the schema.rb parser automatically defines foreign key constraints whenever a relationship is present due to its specification.

Because of these kinds of parser-specific behaviors, it can be difficult to unify all outputs under a single shared test case generator. While it’s sometimes possible to craft input data that leads to consistent results, doing so may make test maintenance harder and more fragile.

Additionally, there are already tests that don't rely on shared output. Since test implementations are no longer fully standardized, this could cause confusion when adding new test cases.

---

If the goal is to test that all parsers share a common set of features, it might be better to standardize the structure of the test blocks themselves rather than the output itself. For example, we could define a common test structure that is reused across all parser tests. Since the output of each parser is of Schema type, I believe the test structure should closely resemble the structure of the Schema type to ensure the tests cover all necessary functionalities.

describe(processor, () => {
  describe('table', () => {
    it('column', () => { ... })
    it('not null column', () => { ... })
    it('default value as string', () => { ... })
    it('default value as integer', () => { ... })
  })

  describe('indexes', () => { ... })

  describe('constraints', () => { ... })
})

In cases where a feature hasn't been implemented yet in a particular parser, we can use it.todo or describe.todo to maintain the shared structure while clearly indicating that the feature is pending.

describe(processor, () => {
  describe('table', () => {
    it('column', () => { ... })
    it('not null column', () => { ... })
    it('default value as string', () => { ... })
    it('default value as integer', () => { ... })
    ...
  })

  describe('indexes', () => { ... })

  describe.todo('constraints') // this line shows the parser doesn't support the `constraints` feature yet.
})

TODO (Optional)

• [ ] design a common test structure for all the parsers
• [ ] migrate the tests

Additional notes (Optional)

[MH4GF]

Thanks! Go ahead 🚀

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.