Scan test classes for JAXRS annotations?

[fabiosimeoni]

Hi Kumuluzz seems to work well for exploded, out-of-container testing, but I haven’t found an obvious way to get Jersey to look at my test classes when scanning ( like CDI does). I have some fake APIs that I’d like to be picked up for smoke tests and for testing error handling and other cross-API features. It’d also be nice to do this for symmetry with CDI.

The support for scan-libraries in 3.1.0 covers only jars. I think I see some support in ClasspathtAttributes, but not a way to configure it on your server wrapper. Would I need to use an extension for this? If so, how would I go about it.

Thanks! And by the way, Kumuluzz is truly useful, keep up the good work.

[urbim]

Hi!

First of all, the scan-libraries support works for jars and also exploded deployments. I don't think you need to use extensions framework for this, only configure scan-libraries correctly when running your tests.

As for testing, it 's hard to tell what you're trying to achieve based solely on your description. Can you elaborate a bit more on how you are running your tests. Based on your description I think you should take a look at the KumuluzEE Arquillian Adapter and see if the inclusion of Arquillian can simplify your tests.

[fabiosimeoni]

Hi, thanks for the quick reply.

I’m in a standard maven setup, my tests run without Arquillian, simply by starting your EEApplication in an exploded scenario, with config.yml in src/test/resources. I want to test some rest APIs that are under src/test/java but only the classes in src/main/java get scanned.

This is because you configure jetty's webAppContext with target/classes. My question is: how can I tell Kumuluzz/Jetty/Jersey to look also into target/test-classes?

I know scan-libraries work also in exploded contexts, but I meant that I can only configure jar dependencies with it, not plain directories.

For now, am registering an Extension and doing something with your internals as awful as this:

@Override @SneakyThrows
public void init(KumuluzServerWrapper server, EeConfig eeConfig) {

    // waiting to find out a better approach than this...
    log.info("adding test classes to scan path...");

    Field field = server.getServer().getClass().getDeclaredField("appContext");
    field.setAccessible(true);
    WebAppContext ctx = (WebAppContext) field.get(server.getServer());
    ctx.setAttribute(jarPattern, exploded_test+"|"+ctx.getAttribute(jarPattern));

}

As you can see, am forcing this constant:

public class ClasspathAttributes {

…

public static final String exploded_test = ".*/test-classes/.*";

}

which shows you have support for target/test-classes but I didn’t figure out where you use or how I can take advantage of it.

I’d be happy to remove the patch above with a clearer approach.

To reiterare my use case: I have test-only APIs with which I’d like to test various aspects of my application, e.g. how I handle errors, how my exception mappers work, etc. I don’t want this DummyAPI to be in my prod classpath, only my test classpath, hence in target/test-classes.

cheers

f

On 18 Feb 2019, at 10:49, Urban Malc <notifications@github.com mailto:notifications@github.com> wrote:

Hi!

First of all, the scan-libraries support works for jars and also exploded deployments. I don't think you need to use extensions framework for this, only configure scan-libraries correctly when running your tests.

As for testing, it 's hard to tell what you're trying to achieve based solely on your description. Can you elaborate a bit more on how you are running your tests. Based on your description I think you should take a look at the KumuluzEE Arquillian Adapter https://github.com/kumuluz/kumuluzee-testing/tree/master/kumuluzee-arquillian-container and see if the inclusion of Arquillian can simplify your tests.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kumuluz/kumuluzee/issues/132#issuecomment-464662203, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR8IW35pYoz23XvB0tS7IO3AMDNPzzFks5vOncygaJpZM4a-3hP.

[urbim]

Hi!

No, we currently do not have a cleaner approach, however I think this could be added relatively easily.

Would you care to submit a project with a minimal use-case so we can test the implementation? A simple provider in test-classes and a (failing) test that checks its activation would suffice.

[fabiosimeoni]

Sure, find a minimal example here: https://gitlab.com/simeoni/kumuluzz-testclasses.git.

This should show 3 things:

• why one might need to have test classes scanned (in the example, to test an exception barrier).
• how the patch makes it work (cf. KPatch).
• how CDI doesn’t suffer from the issue (as we all know).

Disable KPatch as a service and one of the tests fails.

cheers

f

On 18 Feb 2019, at 13:34, Urban Malc notifications@github.com wrote:

Hi!

No, we currently do not have a cleaner approach, however I think this could be added relatively easily.

Would you care to submit a project with a minimal use-case so we can test the implementation? A simple provider in test-classes and a (failing) test that checks its activation would suffice.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kumuluz/kumuluzee/issues/132#issuecomment-464716192, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR8Id1Q6d02GmJPgaK-5XIikBwIUcThks5vOp3OgaJpZM4a-3hP.

[urbim]

Hi!

We have added a toggle to add test classes on the classpath (see PR). Probably the easiest way to enable the feature in your tests is to define environment variable KUMULUZEE_DEV_RUNNINGTESTS=true. I have tested the implementation with your example and the tests pass without your patch.

[fabiosimeoni]

Splendid, thank you. Will try it out as soon as I can.

F

Sent from my iPhone

On 10 Apr 2019, at 14:39, Urban Malc notifications@github.com wrote:

Hi!

We have added a toggle to add test classes on the classpath (see PR). Probably the easiest way to enable the feature in your tests is to define environment variable KUMULUZEE_DEV_RUNNINGTESTS=true. I have tested the implementation with your example and the tests pass without your patch.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.