Details
-
Type:
Feature Request
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Configuration
-
Labels:None
Description
Microdeployments via ShrinkWrap are a nimble deployment mechanism that allows developers to test bytecode skipping the build. Another usecase is to have ARQ in a CI loop, testing artifacts post-deploy. For this sort of scenario, it would be useful to reuse test cases from the microdeployments, but have them leveraged against code pulled from maven artifacts published in a prior step.
For example, we could have an @Maven annotation which could define the coordinates of an ear file, and place that on a test scenario that performs the war, ejb, cdi, etc tests of from the dependent modules.
Gliffy Diagrams
Issue Links
- relates to
-
ARQ-74
Base test deployment on project in which test is run
-
- Open
-
-
SHRINKWRAP-325
ShrinkWrap.create(MavenImporter.class) that creates a WebArchive that adds all WEB-INF descriptors, classes, test classes and webapp resources too (not just dependencies and test dependencies)
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Initial prototype present at https://github.com/kpiwko/arquillian-extension-maven-deployer
Usage
@Deployments(@MavenDeployment(value = "org.jboss.weld.examples.jsf:weld-jsf-login:war:1.1.1.Final",
|
settings = "src/test/resources/settings.xml"))
|
@RunWith(Arquillian.class)
|
public class WarDeploymentTestCase {
|
...
|
It mirrors all the configuration available for @Deployment methods, such as @Protocol, @TargetsContainer, etc. If extension is activated
but no @Deployments annotation is present, it reverts to default behavior.
I'm falling into following issue with compilation from cmdline:
http://bugs.sun.com/view_bug.do?bug_id=6512707
Somehow works only with OpenJDK, Sun (1.6.0_24) compilation fails. Have to figure it out.
Karel Piwko
added a comment - - edited Initial prototype present at https://github.com/kpiwko/arquillian-extension-maven-deployer
Usage
@Deployments(@MavenDeployment(value = "org.jboss.weld.examples.jsf:weld-jsf-login:war:1.1.1.Final",
settings = "src/test/resources/settings.xml"))
@RunWith(Arquillian.class)
public class WarDeploymentTestCase {
...
It mirrors all the configuration available for @Deployment methods, such as @Protocol, @TargetsContainer, etc. If extension is activated
but no @Deployments annotation is present, it reverts to default behavior.
I'm falling into following issue with compilation from cmdline:
http://bugs.sun.com/view_bug.do?bug_id=6512707
Somehow works only with OpenJDK, Sun (1.6.0_24) compilation fails. Have to figure it out. +1 to JDK 6 only
Adrian Cole
added a comment - +1 to JDK 6 only I managed to make it compile with Sun javac compiler disabling annotation processing in maven-compiler-plugin.
Karel Piwko
added a comment - I managed to make it compile with Sun javac compiler disabling annotation processing in maven-compiler-plugin. Are we still interested in this feature?
Karel Piwko
added a comment - Are we still interested in this feature? completely forgotten to check this one..
On top of my head, setting the maven cords+version in source code doesn't sound to useful. Maybe a arq/extension config, replaceDeployment
Aslak Knutsen
added a comment - completely forgotten to check this one..
On top of my head, setting the maven cords+version in source code doesn't sound to useful. Maybe a arq/extension config, replaceDeployment 
From IRC:
(06:37:24 AM) aaddriancole: so. on arq ... add a @Maven annotation to the arq createArchive methds(06:37:41 AM) aaddriancole: with coordinates as params(06:37:44 AM) ALR: Instead of @Deployment?(06:37:47 AM) ALR: Yeah, that's hot.(06:38:03 AM) ALR: ARQ could internally use the MavenResolver API to work out the details.(06:38:03 AM) aaddriancole: yep... this will force either through instlal or deploy(06:38:07 AM) aaddriancole: yep(06:38:18 AM) aaddriancole: so in xml or whatever, you could change to deploy(06:38:24 AM) aaddriancole: or whatev(06:38:34 AM) aaddriancole: but the point is that you'd have a releaseable artifact(06:38:44 AM) ALR: IMO we still have some work to do regarding defining N deployments and *when* they're deployed.(06:38:52 AM) ALR: But I know aslak has some ideas there(06:39:05 AM) aaddriancole: yeah. this is a good point(06:39:07 AM) ALR: Though the @Maven thing may not help with the "current" artifact.(06:39:15 AM) ALR: We still don't have a great solution for the "current"(06:39:23 AM) ALR: Because "current" may not be built/installed!(06:39:31 AM) aaddriancole: well, it could help in a way..(06:39:35 AM) aaddriancole: here's one idea(06:39:38 AM) aaddriancole: after tests pass(06:39:41 AM) aaddriancole: it is published(06:39:46 AM) aslak: ALR, well, current would be bind to integration-phase and import your builds output(06:39:56 AM) ALR: aslak: integration-test is *before* install.(06:40:08 AM) ALR: Yet after package.(06:40:15 AM) aaddriancole: oh yeah.. well this is a good point(06:40:23 AM) aslak: ALR, aa, for using the Resolver sure, but you can still import the packaged artifact(06:40:26 AM) aaddriancole: I mean most projects are running maven so there's overlap on this thing(06:41:01 AM) ALR: Alternatively, bind the test lifecycle to "validate" or "verify", whichever of those is the really late-running one after install.(06:41:15 AM) ALR: But no one's gonna wanna put that in the Surefire config in the POM.(06:41:20 AM) aaddriancole: heh(06:41:36 AM) aaddriancole: maybe you can have a sneaky arq agent :)(06:41:46 AM) ALR: aaddriancole: An aside, you been following AS7 at all?(06:41:47 AM) aslak: true, but i'm not a fan of making arq your build tool either(06:41:58 AM) ALR: aslak: +1. Arq ain't a build tool.(06:42:25 AM) aaddriancole: yeah. but I like the idea of getting tested components releasable(06:42:32 AM) aaddriancole: even if it isn't a good idea :p(06:42:47 AM) ALR: aaddriancole: IMO the testsuite would be in a separate module(06:42:55 AM) ALR: Which would then depend upon the components you're looking to test(06:43:17 AM) aaddriancole: ALR p.s. haven't been following too closely AS7, except mopping up aslak's puddle of drool related to how fast it is(06:43:18 AM) ALR: So like the testsuite module would depend on the CDI or EJB module(06:43:25 AM) ALR: And just deploy the @Maven thing.(06:43:42 AM) aaddriancole: yeah that's a good way out(06:43:47 AM) ALR: aaddriancole: It gives us what's shaping up to be the fastest EE runtime. We're very excited.(06:44:14 AM) ALR: So yeah, I'd say for best practices: Make an EJB module, a WAR module, whatever. And the testsuite depends upon and deploys those.(06:44:28 AM) aaddriancole: sounds good to me(06:44:37 AM) ALR: In that sense the ARQ test would mimick the *real* thing you're gonna deploy(06:44:42 AM) ALR: Not a manual ShrinkWrap deployment(06:44:54 AM) ALR: (Which I still love for its explicit nature and simplicity)(06:44:56 AM) aaddriancole: yeah well this could be the next layer as well(06:45:07 AM) aaddriancole: I mean you could extend the integration test classes(06:45:10 AM) aaddriancole: and override somehow(06:45:20 AM) aaddriancole: instead of the shrink ones, use maven(06:45:31 AM) ALR: Why bother extending them(06:45:33 AM) ALR: ?(06:45:52 AM) aaddriancole: well, I suppose the point would be being able to rerun the regression tests(06:45:52 AM) ALR: When you can just move the int-tests into another module?(06:46:04 AM) aaddriancole: oh all of them?(06:46:11 AM) aaddriancole: well... maybe you're right(06:46:12 AM) ALR: I suppose so.(06:46:14 AM) ALR: Yeah.(06:46:20 AM) aaddriancole: just that shrink is still more nimble(06:46:20 AM) ALR: Unit tests in the component modules.(06:46:28 AM) ALR: ARQ integration tests in a separate module.(06:46:36 AM) ALR: And that becomes our recommendation for best practices.(06:46:45 AM) ALR: For testing real build artifacts(06:46:45 AM) aaddriancole: you don't have to build dependency graph to test minor bits if you keep some shrink in(06:46:50 AM) ALR: Otherwise assemble on your own(06:46:54 AM) ALR: "Microdeployment"(06:46:57 AM) aaddriancole: not sure yet if the combination is too complicated(06:47:00 AM) ALR: And you can test those wherever you want.(06:47:14 AM) ALR: Right, minor bits == microdeployments.(06:47:16 AM) aaddriancole: unit being microdeployment?(06:47:18 AM) aaddriancole: yeah(06:47:21 AM) ALR: No big bang testing.(06:47:31 AM) ALR: Well, microdeployment is still integration.(06:47:34 AM) ALR: For instance:(06:47:40 AM) ALR: Your EAR is the big kahuna.(06:47:52 AM) ALR: The EAR may have web, EJB, CDI, etc....lots of stuff.(06:48:02 AM) ALR: But microdeployments, maybe you just test the EJB on its own.(06:48:19 AM) ALR: I have some slides on this.(06:48:24 AM) ALR: You're a musician, right(06:48:24 AM) ALR: ?(06:48:27 AM) aaddriancole: :)(06:48:29 AM) aslak: the question on how to run your arq tests on your final deployment has come up, as in you have a bunch of microdeployments that run fine, but you also want to run the same ones on the final deployment. i hvae some thought on it, but not 100%(06:48:46 AM) ALR: Microdeployments: Test that your phaser pedal, your tuner is working.(06:48:58 AM) ALR: Full integration: Test that your whole pedalboard is wired up to the amp.(06:49:28 AM) ALR: aslak: I think this is the missing gap for the "final" deployment case.(06:49:34 AM) aaddriancole: yeap(06:49:36 AM) ALR: 1) Make a separate module(06:49:44 AM) ALR: 2) Define deployment by resolving through Maven.(06:49:49 AM) ALR: Giving you the "real" stuff.(06:49:55 AM) ALR: As generated by the build system.(06:50:45 AM) aslak: sure, but using the same tests(06:51:04 AM) aaddriancole: well this is the crux of the talk.. should this run the same tests again?(06:51:05 AM) ALR: Where does @Maven go?(06:51:15 AM) ALR: Not on a method, I wouldn't think.(06:51:15 AM) aslak: it can be done by having a separate module, extending a base test that defines the test assertons and in each module define the deployment etc, but it's not very pretty(06:51:20 AM) ALR: On the test class?(06:51:38 AM) aaddriancole: well, this is a tricky annotation isn't it(06:51:40 AM) ALR: @Deployments({@Maven(gav1), @Maven(gav2)})(06:51:51 AM) aaddriancole: oh(06:52:18 AM) aslak: would be on the Class i think. seems silly to make a method just for the annotation(06:52:26 AM) ALR: In this sense, no @Deployment static method in the test class, it'd just be an annotation of deployments upon the test class(06:52:30 AM) ALR: Right.(06:52:40 AM) ALR: @Deployments(array)(06:52:48 AM) aaddriancole: yeah I mean ARQ could make some assumptions right?(06:52:50 AM) ALR: @Maven is a fully-declarative deployment(06:52:57 AM) aaddriancole: if @Deployments on class, ignore static(06:53:03 AM) ALR: And actually...(06:53:13 AM) ALR: @Maven should have @Deployment as a meta-annotation in it.(06:53:28 AM) ALR: So that users could put in ANY user-defined special annotation(06:53:39 AM) ALR: So long as it was itself @Deployment(06:53:41 AM) aslak: it's no biggy to impl. the extension point is there. you can override the whole @Deployment method handling using the DeploymentScenarioGenerator.(06:53:42 AM) aaddriancole: makes sense.. I mean we may need to have @OSGi at some point(06:54:06 AM) ALR: @Deployment(06:54:06 AM) ALR: @interface OSGi{}(06:54:09 AM) ALR: Same deal.(06:54:16 AM) aaddriancole: aslak I'm not surprised you have a means of handling this cleanly :)