Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Support "AND" logic to tags for the tests runner #1042

Closed
@alexeyhimself

Description

@alexeyhimself

Is your feature request related to a problem? Please describe.
We use different kinds of tags to formulate a scope for the tests run. We have different kinds of tests: post deployment verification (pdv), functional, data quality evaluation (dqe) tests, unit tests and so on. We have different kinds of releases (relatively defined: current, next; explicitly defined: v63_0, v63_1, v64_0) as well. And we'd wanted to run test cases among these categories.

For example, we'd wanted to run all "p0 tests in v64_0 release". We have tests tagged with priorities: "p0", "p1", "p2", "p3". We have tests marked with category: "pdv", "dqe", "functional", etc. We have special tags like: "long_running", "not_for_production", etc. We have release tags: "v63_0", "v64_0", etc. And we tag our tests, for example, as follows:

--%tag(v64_0, pdv, not_for_production)
--%tag(current, pdv)
--%tag(current, p0, functional)
--%tag(current, p0, performance)
--%tag(current, p1, functional)
--%tag(v63_1, dqe, long_running)

When we want to run all "p0" tests in "v64_0" release, we have no way to do it now. We either run all "p0" tests or all "v64_0" tests, or both - due to "OR" logic for the tests run. We want both "OR" and "AND" logic as well - to form different kinds of tests scope.

Describe the solution you'd like
We'd wanted you support this kind of separators to apply different kinds of logic to the tests runner:

select * from table(ut.run(a_tags=>'p0||p1')); -- "OR" logic
select * from table(ut.run(a_tags=>'p0&&v64_0')); -- "AND" logic
select * from table(ut.run(a_tags=>'(p0||p1)&&v64_0')); -- mixed logic with priority defined by ()

Describe alternatives you've considered
Alternative to this - is to use self-written tests installer to cleanup all test procedures before tests run and install only required tests and run all installed tests. I.e. alternative - is to delegate this scope defining function to the self-written installer. This is not useful and not nice. And this installation-deinstallation packages activity produces db system logs that we don't want. We'd better installed our tests once and then run subsets of them on demand.

Additional context
No

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions