search

ingwarsw / arquillian-suite-extension

Arquillian extension that will force single deployment for all tests
Apache License 2.0
67 stars 20 forks source link

Better support for multiple deployments #24

Closed pazoozooCH closed 7 months ago

pazoozooCH commented 9 years ago

Hi

This might go a bit into the direction of #23, but I still thought I'd open a new issue.

I'm having integration tests that share a few deployments. However, I would really want to have different base classes to define them. I'm not really getting a few points:

  1. Why is the classpath scanned to find the ArquillianSuiteExtension annotated class? This takes a couple of seconds with my setup. Wouldn't it be possible to just look through the class hierarchy of the test class? Or could you at least allow to define the class somehow else, through a system property, file or something else (may be opt-in)? A few seconds might not be that bad on a CI-Server, but they really count when doing TDD locally on a single test base...
  2. Why can I only have a single class annotated with ArquillianSuiteExtension? This breaks my whole setup of having distinct base classes for my distinct test groups / deployments.
  3. The @OperateOnDeployment annotation might be an option, but I can only define it on method level, not on an entire class. If I defined all my deployments in a common base class, I would still need to annotate ALL test methods in order to get it working which would be rather annoying.

Are these general limitations of your extensions or am I applying it somehow unexpectedly?

Thanks Martin

ingwarsw commented 9 years ago

Hello,

Because arquillian is bit awkward and not supports suites, that extension is trying to compensate it as possible. Thats why some things needs to be done in not always best way.

  1. That was done by design, to simplify creating that classes. But I see no problem at adding system or arquillian property to just find class.

2, 3. In plain arquillian its simple, you have test class and you are looking for deployments inside it. Only when you find more than one deployment you need to specify witch one use by @OperateOnDeployment annotation (witch is plain arquillian annotation).

With that extension you have all your deployments available for all test classes so you need to decide witch one would you like to use.

Probably would be possible to create something more complex witch own annotations stating witch deployments use but Im not sure if its worth it.

Could you elaborate a bit more about your setup?

pazoozooCH commented 9 years ago

Thanks for the feedback. Regarding 1, would be great if you could add a mechanism to avoid the classpath scanning, e.g. specifing the class name in a resource like META-INF/arquillilan-suite-extension.deploymentClass or something alike...

Hm, I haven't looked into details of how the suite extension is hooked up with Arquillain. Suppose the following setup (I'm using dummy names, but I'm sure you get the concept):

I guess you get the picture: I have multiple micro (or not so micro) deployments that I define in base classes. With pure Arquillian, this works like a charm. Arquillian find the deployment through class inheritance, everything is fine. Except that multiple extending classes will re-deploy the same deployment. Here, the suite extension could come into play. But it won't work with that setup as I have multiple classes that define deployments.

One solution would be to extend CustomerBaseTest and ContractBaseTest from a common base class, let's say DeploymentBase and declare all deployments in there. Then I could add the suite extension annotation on that class. But then I would have to annotate ALL test methods with an @OperateOnDeployment annotation which is not very nice.

Do you think there might be a siple fix for that or would it be too hard to integrate with Arquillian?

pazoozooCH commented 7 months ago

I'll close this, not using Arquilian anymore...