There is an annotion -- %disabled you can use. If you join that with conditional compilation should work.
Hope it helps.

Cool idea @lwasylow. But this does not work. Here's an example:

create or replace package test_xyz is

  --%suite
  --%suitepath(alltests)

  --%test
  $if dbms_db_version.version > 10 $then
    --%disabled
  $end
  procedure t1;

  --%test
  --%disabled
  procedure t2;

end test_xyz;
/

set serveroutput on size unlimited
execute ut.run('test_xyz');

Output is

Package TEST_XYZ compiled

alltests
  test_xyz
    t2 [0 sec] (DISABLED)
 
Finished in .001528 seconds
1 tests, 0 failed, 0 errored, 1 disabled, 0 warning(s)
 


PL/SQL procedure successfully completed. 

The best alternative is --%tags. #983 might improve the usage in coming releases. But there is no way to disable tests dynamically AFAIK.

Ahh annotation parser reading from dba_source and conditonal compilation breaking pattern.

It's not about annotation parser.
We consider conditional compilation.

This works as you would like it to:

create or replace package test_xyz is

  --%suite
  --%suitepath(alltests)

  $if dbms_db_version.version > 10 $then
  --%disabled
  --%test
  procedure t1;
  $else
  --%test
  procedure t1;
  $end

  --%test
  --%disabled
  procedure t2;

end test_xyz;
/

set serveroutput on size unlimited
execute ut.run('test_xyz');

Test procedure t1 is disabled on some versions of Oracle.

Reason why original example didn't work is that after running through pre-processor, the package spec looks like this:
On Oracle <=10

create or replace package test_xyz is

  --%suite
  --%suitepath(alltests)

  --%test



  procedure t1;

  --%test
  --%disabled
  procedure t2;

end test_xyz;

On Oracle >10 it looks like this:

create or replace package test_xyz is

  --%suite
  --%suitepath(alltests)

  --%test

    --%disabled

  procedure t1;

  --%test
  --%disabled
  procedure t2;

end test_xyz;

So the test and disabled annotations are "floating" and so:

• whole package (suite) is disabled
• procedure t1 is not a test procedure at all (and is not showing on test results.

@PetrShchukin - does that answer your question?
Do you have any further questions?

@jgebal Thanks, that works fine when we need skip one-two tests, but if our test contains ~10 tests and we need to skip five, it becomes clumsy. I tried to use disable annotation to context but it seems it doesn't work.

It's not about annotation parser.
We consider conditional compilation.

This works as you would like it to:

create or replace package test_xyz is

  --%suite
  --%suitepath(alltests)

  $if dbms_db_version.version > 10 $then
  --%disabled
  --%test
  procedure t1;
  $else
  --%test
  procedure t1;
  $end

  --%test
  --%disabled
  procedure t2;

end test_xyz;
/

set serveroutput on size unlimited
execute ut.run('test_xyz');

Test procedure t1 is disabled on some versions of Oracle.

Reason why original example didn't work is that after running through pre-processor, the package spec looks like this:
On Oracle <=10

create or replace package test_xyz is

  --%suite
  --%suitepath(alltests)

  --%test



  procedure t1;

  --%test
  --%disabled
  procedure t2;

end test_xyz;

On Oracle >10 it looks like this:

create or replace package test_xyz is

  --%suite
  --%suitepath(alltests)

  --%test

    --%disabled

  procedure t1;

  --%test
  --%disabled
  procedure t2;

end test_xyz;

So the test and disabled annotations are "floating" and so:

* whole package (suite) is disabled

* procedure t1 is not a test procedure at all (and is not showing on test results.

Sorry, I don't see what's wrong here, in the first case there is no disable annotation, in the second disable annotation is below test annotation. Why should a suite be disabled? Do lines between annotation play a role?

What do you mean it doesn't work? Can you give an example?
Also. I'm still not sure as to what is it that you try to achieve?

Why do you need to run part of tests conditionally? If you provide a bit more context maybe we can suggest a better solution.

You said:

...I want to skip some tests depends on system settings or stop a whole test...

What kind of system setting do you have in mind?
Do you want different tests to be ran on different environments or within same env but depending on user/role/machine that invokes the tests?

The better you describe the problem, the more likely you are to get a valuable and helpful answer.

Sorry, I don't see what's wrong here, in the first case there is no disable annotation, in the second disable annotation is below test annotation. Why should a suite be disabled? Do lines between annotation play a role?

Yes.
An annotation is considered related to procedure only when it is placed directly before the procedure (no empty lines).
Seems like it is not explicit enough in the documentation.

Documentation is pretty comprehensive, still studying)
Let's say there are 100 different tests(packages). 15 of them are for testing 15 microservices. Each of them has 10 test inside, 5 for testing a microservice on itself, five is about sending messages. Depends if other services are available and just say versions are compatible I want to test sending messages as well, if not I want to skip the test. Maybe it's not a good way to create a test though.
And what about disable context, I'll try again, so I can use disable to context, right? But if pre-processor add lines, I need to copy all context in else block.

Conditional compilation , disabling tests isn't probably what you are looking for.

But yes, you can do this:

create or replace package tst is

--%suite

--%context(first)
--%disabled

--%test
procedure t1;

--%endcontext

--%context(second)

--%test
procedure t2;

--%endcontext
end;
/
create or replace package body tst is

procedure t1 is begin ut.expect(1).to_equal(2); end;

procedure t2 is begin ut.expect(1).to_equal(2); end;

end;
/


exec ut.run('tst');

Thanks!

You can also use tags, as mentioned by @PhilippSalvisberg

create or replace package tst is

--%suite

--%context(first)
--%tags(integration)

--%test
procedure t1;

--%endcontext

--%context(second)
--%tags(microservice)

--%test
procedure t2;

--%endcontext
end;
/
create or replace package body tst is

procedure t1 is begin ut.expect(1).to_equal(2); end;

procedure t2 is begin ut.expect(1).to_equal(2); end;

end;
/

exec ut.run('tst', a_tags=>'microservice');
exec ut.run('tst', a_tags=>'microservice,integration');
exec ut.run('tst', a_tags=>'integration');
exec ut.run('tst');

I would personally separate integration tests from standalone micro-service tests

The isolation could be done by:

• separate suite packages
• contexts
• tags

suites and tags seems like most flexible way.
You know you can use suitepath to group tests that share common purpose (subject)?
You can run all tests that are on the same suitepath by providing suitepath as a run option.

Yeah, probably it would be better to use separation on a higher level, thanks!

Another option would be to have separate test suites (packages) for different types of tests.

So it seems there are few ways to address your question.