11:10 a.m.
>
> by "real testing" I mean you are running against the "real" thing
and not some stripped down server/deployment.
ARQ does not strip anything down. It's a plumbing layer only; it
bridges the JUnit/TestNG lifecycle and plugs it into server lifecycle,
adding in things like deployment and injection along the way. ARQ
enables testing as "real" as the target container adaptor you choose.
The deployments are "stripped down" (for a good reason)
> And unless i'm completely misunderstanding you then the
start/stop of a server via ARQ is still doing the "lifecycle" of a
junit/integration test run.
Yes. You mention later in this Thread that by "real" you mean "manual
verification". ARQ automates by either starting or connecting to a
server as part of the test lifecycle.
yes - thus that is where the possible "collisions" can occur.
For starting/stopping results it port conflicts if you have a running server.
For connecting there is possible deployment overlaps.
That is all i'm saying - and just wondering if there is something we could do to
minimize those
"conflicts" ....possibly there isn't and its just a matter of documentation
and improving error messages.
> Just because ARQ provides this does not mean the
"live"/"real" running on the server goes away ?
Huh? If you use the Remote connector, then ARQ will disconnect from the
server you have running. In Embedded or Managed, it shuts down the
server it started.
yes - and I was getting from your previous mails as if we should be going away from the
practice of
hotdeployemnt/manual verification.
ARQ removes alot of the need for that - but it will still be around thus just a thing to
be conscious about.
btw. snjezana started outlining ideas for Arquillian support/integration into the IDE
..thats where some of these things
might be popup...http://community.jboss.org/wiki/JBossToolswishlist
>> The most isolated run mode is Remote, which yes, most closely
reflects a
>> production environment. I like to encourage the notion of using
>> whatever run level is appropriate, and also use many layers of testing.
>
> Yes, but unless ARQ has some serious magic going on it is still not as fast as the
IDE to do incremental deployments
> and there is other tooling setup/configuration that is hard/requires a lot of work of
the very userclasses dependent ARQ approach.
ARQ's not doing incremental deployments. Again, the entry point is the
JUnit/TestNG harness.
Yes - so its a different usecase.
Course, when you have a server as fast as AS7, the time to boot a new
server instance is IMO negligible. And incremental deployment, however
useful during development, is not "real" by any stretch of the
imagination. :)
AS 7 is not the only server in the world - and even if it was quick startup does not
change the fact
that keeping session state and running context "live" is very useful for live
debugging and incremental changes
of JSF, GWT, XHTML pages and other "live" technologies.
/max
http://about.me/maxandersen