Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

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

Copy link
Copy link
Closed
@alexeyhimself

Description

@alexeyhimself
Issue body actions

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

    Morty Proxy This is a proxified and sanitized view of the page, visit original site.