Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameterize regression test suite with DDL sharding key #208

Closed
ligurio opened this issue Sep 2, 2021 · 3 comments
Closed

Parameterize regression test suite with DDL sharding key #208

ligurio opened this issue Sep 2, 2021 · 3 comments
Labels
code health Improve code readability, simplify maintenance and so on wontfix This will not be worked on

Comments

@ligurio
Copy link
Member

ligurio commented Sep 2, 2021

parameterization is coming to luatest [1], it would be nice to parameterize the whole test suite with an option that enables/disables custom sharding key to make sure that everything is fine.

  1. Implement group parametrization luatest#163
@kyukhin kyukhin added the code health Improve code readability, simplify maintenance and so on label Sep 3, 2021
@kyukhin kyukhin added this to the wishlist milestone Sep 3, 2021
@Totktonada Totktonada removed this from the wishlist milestone Sep 6, 2021
@Totktonada
Copy link
Member

The sharding keys support comes with tests (PR #181), so I guess here you propose to coalesce the similar tests cases. My thoughts on the topic are below.

  1. It is hard to verify that we don't miss some cases if we'll do a massive tests rewritting.
  2. Those new tests will be more abstract and less straighforward.
  3. It is considerable amount of thorough work.
  4. However if we'll define a set of simple tests that can be written in an abstract way and run against different schemas, we can easily add a new case to verify against all those schemas.

I found the idea of using parametrization in new tests, where it is appropriate, nice. But I doubt about rewriting of existing tests. However I'm not the author of tests, so my judgement may be a bit too abstract.

@ligurio, what do you think here?

@ligurio
Copy link
Member Author

ligurio commented May 23, 2022

I agree. Feel free to close the issue.

@Totktonada
Copy link
Member

Closing then. // CC @DifferentialOrange

@Totktonada Totktonada closed this as not planned Won't fix, can't repro, duplicate, stale Jun 4, 2022
@Totktonada Totktonada added the wontfix This will not be worked on label Jun 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code health Improve code readability, simplify maintenance and so on wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants