Arquillian at its core is an adaptor between a test framework (JUnit, TestNG) and any container. Here we define “container” as: “An application which hosts and provides services to other applications.” In that sense, even Spring may be (and is) a backing “container”. So Arquillian is extensible testing platform with many different runtime targets; Spring Test is clearly bound to the Spring Framework.

I can absolutely see why users coming from a Spring background don’t grok the need for ShrinkWrap or @Deployment. In a flattened classpath without deployments, of course this is superfluous. But many other containers, Java EE included, use the notion of a deployment and ShrinkWrap is the mechanism we use to allow users to specify its contents. Think of it as a Java Object analogue to a standard JAR; only we don’t make you run a full build, serialize a physical file, or any of that. With ShrinkWrap you can take advantage of IDE incremental compilation and run straight from the IDE’s test VM launcher.

That said, yes, using the plain ShrinkWrap Archive API to make deployments could be redundant if you’re already using Maven to package up your deployments. For this case we provide the ShrinkWrap Maven Resolver API, allowing users to resolve a set of Maven Coordinates to ShrinkWrap archive(s). An example of that usage looks like this[1].

The issue of a natural default for Tx is one on which we should continue to get opinions. For instance I’ve got tests that, in the case of one method, need to execute many Txs and ensure the persisted state (from the outside, testing isolation) is as expected.

S,
ALR

[1] https://github.com/arquillian/arquillian-showcase/blob/master/multinode/src/test/java/com/acme/multinode/grid/Deployments.java#L37

I’m curious, what do you think you do better than spring-test? I’m not trolling I really want to know. Sometimes you don’t know what you’re missing until somebody shows you.

I don’t understand the need for ShrinkWrap. The way I understand it what you posted here is just a best case secenario. I imagine once you have to package all the transitive dependencies of a class and versioned artifacts (eg. Maven) it gets quite hard to mantain. For example when you update to a new library you have to update all your ShrinkWrap definitions. Once a class depends on an other class you have to update all your ShrinkWrap definitions.

Regarding transactions I found [1]. I just can’t imagine why per default you would want tests that modify the database.

[1] http://community.jboss.org/thread/154778

So great feature request for a declarative way to deal with transactions scoped to the test method. I’m thinking something like @Transactional(rollback=boolean) should do the trick. Course, I wouldn’t make this a default at all; I like stuff to be explicit and easily-defined. There are lots of other hooks to reset test state to default values ie. DBUnit and I don’t think we should step on any toes or presume to muck w/ Txs unless otherwise instructed.

And don’t you think you’re rushing to judgement on Arquillian over just this one point? Arquillian is a test platform; it adapts the test lifecycle into *any* backing “container”, including other test frameworks like Selenium. I think you’d be doing yourself a disservice to disregard the power and portability of Arquillian over this one point. And yes, we feel we do many things better than Spring Test (and from the feedback we’ve gotten recently, many users agree).

Maybe you’d like to join us w/ some contribution? Your experience in the area could help shed some light on weaker pieces and let us buff up in those areas.

S,
ALR

You’re obviously up against spring-test. spring-test runs the tests in a (Spring) container as well without needing any IDE tooling as well. In addition per default it runs each test in a transaction and rolls it back after the test (zero lines of Java or XML). This makes sense as a default because per default you don’t want to have tests that commit (or have any other side effect). Arquillian does not support this. You have to inject a UserTransaction or EJBContext and manually roll back after the test. In addition you don’t need to muck around with deployments in spring-test, I mean why would you?

I have a need to build a corba server in jboss as a replacement for an existing standalone corba server as java application. I’ll implment a corba servant (which implements the corba interface) as a facade, which delegates to local ejb session bean (where the real meat of the replacement will be implemented). I think the best way to implement a servant in jboss is to implement a microcontainer pojo.

It doesn’t look like microcontainer would inject the ejb proxy as part of the jboss-beans.xml file, as in: . That would be too easy, I guess.

So, I’m left with doing two models at the same time. The corba servant would declare a field with the @EJB annotation. And the code above would cause it to be injected. I don’t understand enough about the microcontainer, but from what I see so far, I think it would be simpler if my corba servant simply did a lookup against an InitialContext for the ejb.

Thanks for the article.