Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

Testing in JEE 6? Same Old Story: Not There

09.20.2010
| 4808 views |
  • submit to reddit

OMG. Maybe I went from sippy cup to gulping the koolaid on JEE 6 a bit too quickly. Went to make a simple test today of my project, you know, so I could write more code that, um, worked, and found out that Weld doesn‘t really provide testing yet of the bean container. I wish I could say I was lmao, but it‘s really so pathetic it‘s sad.

Look at these surreal discussions:

Someone who started to do a runner in JUnit and bailed
On what is a unit?..

‘Hey Jim, did you bring the tests?.... ask Pete.. huh, ok… crap, I know we talked about tests….‘

Tried to make a test following the model of the last item on that thread but it didn‘t work: said there was no bean.

Seriously, decade and a half and we are still not able to do a helloworld with beans that has a test.

I have a radical proposal for a revision to the Agile Manifesto: when assembling a stack, if any part of it is not easily covered by testing, provided as part of that stack, MOVE ON!

Update : Ok, so I went and looked up the error. I don't see how Weld-SE testing works. It just doesn't find the beans. One thread said 'you need a beans.xml in src/test/resources/META-INF' (didn't work). Another said use Arquillian. I went and looked at that, but even if you can get that going now with Weld, their page shows (in the support matrix) that there is no support for persistence yet. Awesome. Ok, well, then I can use this on all my projects that don‘t need to save anything..!

 

From http://www.jroller.com/robwilliams/entry/testing_in_jee_6_same

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Ronald Miura replied on Tue, 2010/09/21 - 4:22pm

Use Spring.

Sudhakar Ramasamy replied on Tue, 2010/09/21 - 7:29pm

I hope someone on the weld team can disprove this. Or else this would not help the adoption of JEE. I've stayed way from JEE ever since i bought into Spring one key reason being testing.

Grzegorz Grzybek replied on Tue, 2010/09/21 - 10:30pm

I'll say something original - use Spring :)

Andy Gibson replied on Wed, 2010/09/22 - 1:27pm

Hey Rob,

Weld doesn't implement Persistence Context injection, that is a feature of the container. There is support for persistence contexts if you are testing in the container, especially if you are testing using full blown EJBs which have their PCs injected by the container. I have no idea why the reference documentation shows that there is no persistence context injection in any container, and can only think that they haven't kept that part of the documenation up to date (Arquillian is still under development). 

Weld isn't responsible for managing and injecting persistence contexts, either the container is or you are if you are testing in a servlet container or on an SE environment.In the demos I wrote (that I know you have seen) I produce the persistence context manually and inject it using a regular @Inject point.

Cheers,

 Andy

 

Rob Williams replied on Tue, 2010/09/21 - 11:04pm

I've used Spring for years. Their testing was good, became a huge mess, then got good again. I'd love to see this disproven too. I have been keeping dibs on Andy's herculean efforts (thinking of the augean stables) in trying to get Weld/JEE projects going that have testing (Arquillian). But I am just still flummoxed as to how in hell this could have happened. Tragic.. Maybe Arquillian will save the day. Again, the question is when. Lots of Red Hat stuff in utero.

Dan Allen replied on Wed, 2010/09/29 - 8:57pm

Rob, I can assure you it's not the same old story. We just need to do a better job of linking up the resources so you know where to turn. I'll provide some insight in my reply, which I'll be sure to communicate on the Weld pages as well.

We are definitely in alignment that a programming model should help you write for testability. Given that CDI beans do not require a single annotation to become components, that makes them as easy to test as any other programming model.

But, unit testing a class and seeing that class function as a component inside the context of a container (standalone or full profile) serve very different purposes. As you suggested, you want to see this stuff really work. I absolutely agree. I don't trust that all those magic methods will be invoked unless I can somehow verify it in an integration testing environment. That's why we are working like crazy on Arquillian.

Arquillian is a container-oriented testing framework that allows you to write integration tests using real components in the same way declarative style that you write your application code (think dependency injection and lifecycle management).

Arquillian is Weld's solution for testing beans. It's just not called Weld test. The reason the project is separate from Weld is because Embedded Weld is one of the many containers that Arquillian supports. The reason it supports many containers is because we all have different container requirements and being able to run a test on more than one environment often provides more feedback about how well a component works. And Arquillian extends beyond Java EE as well.

Testing a HelloWorld class is very simple.

public class HelloWorld
{
   public String greet(String name)
   {
      return "Hello, " + name;
   }
}
@RunWith(Arquillian.class)
public class HelloWorldTestCase
{
   public Archive<?> createDeployment()
   {
      return ShrinkWrap.create(JavaArchive.class)
         .addClass(HelloWorld.class)
         .addManifestResource(EmptyAsset.INSTANCE, "beans.xml");
   }

   @Inject HelloWorld bean;

   @Test
   public void testGreet()
   {
      assertEquals("Hello, Earthlings", bean.greet("Earthlings"));
   }
}

Then you can run this with a couple of dependencies in your Maven project (groupId:artifactId:version)

  • javax.enterprise:cdi-api:1.0
  • junit:junit:4.8.1
  • org.jboss.arquillian:arquillian-junit:1.0.0.Alpha4
  • org.jboss.arquillian.container:arquillian-weld-se-embedded-1:1.0.0.Alpha4
  • org.jboss.weld:weld-core:1.0.1-Final
  • org.slf4j:slf4j-jdk14:1.5.10

We do have support for persistence testing in Arquillian, you just have to use a container which provides it. Right now the options are either Embedded GlassFish or any remote JBoss or GlassFish container. Weld will never provide persistence because that's not part of the CDI programming model. It's intended to be combined with JPA for persistence.

I hope that helps steer you in the right direction. I'll take your post as a sign that we need to communicate the message in more places. Pardon the dust as we work to get Arquillian beyond the Alpha phase. It's happening quickly.

Rob Williams replied on Thu, 2010/10/07 - 12:24am in response to: Dan Allen

Thanks for the post, Dan! Arquillian looks like the real deal after generations of false prophets in the integration testing space. I am going to pick this up again tomorrow. Look forward to it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.