The fruits of working out

This a little tale about some code which didn’t exercise in order to work on the really important.

A couple of months ago our project entered in total-madness mode. We were weeks away from the release and some bugs were still pending – a few critical. So, the management solution was dictated: All of the resources (meaning the members of the development team) will work as long as 24 hours per day if necessary until the bugs list is reduced to zero. Read the rest of this entry »

To consider when arquilling

After a few weeks of real world testing with Arquillian I’ve noticed a few things to consider when building integration tests. These items should grow or evolve, here or in other post, as experience is gained.

To manage provided dependencies. The building of a project most of the time considers dependencies to libraries, toolkits, frameworks, etc., and for each of them you define a scope. You find some to be provided-scoped as your company’s login jar, the jee6-spec.jar library, etc. What’s to consider here is that these libraries are provided by the environment, so they don’t need to be in your deployment file. If you just drop them in your deploy or lib folders when you start the container, without your test file yet, you can make sure the can actually deploy by them selves. Then, if your test-deployment-file fails to deploy it’s less likely because of the provided dependencies. Read the rest of this entry »

Code coverage with Maven and Cobertura

Cobertura‘s usage is covered in its page so that you can install the plugin and run it separately from the build lifecycle. This how-to integrates it with maven3 to run as part of the site lifecycle. Read the rest of this entry »

Having richer tests with Arquillian

Let’s add an auditing feature to the previous post‘s example. As simple as writing into a log file everything that went through the save business method in the employees’ service. To do so, we need to add an appender to the jboss-log4j.xml file, code an interceptor and register it with the method.

To test this interceptor class is doing its job you need to access the audit.log file, something inside the application server. I t means it’s necessary to enrich the test case with a reference to this file. In Arquillian, test enrichment “means hooking the test class to the container environment by satisfying its injection points“. What we are going to inject into the test class is the log file so we can check it’s growing up with the logs from the interceptor.

Code

log-enricher.tar and lunch-ejb-enriched.tar

Read the rest of this entry »

Testing resource injection with Arquillian

After coding a simple component that uses an injected datasource to get a connection, we need to test it. To do so we should choose a testing tool  like JUnit and prepare some mock classes, run the tests, pass them and fail on production because running over the actual application server has some big differences.

This time it’s gonna be different.  From our toolbox we’ll take for a spin our brand new testing tool: the Arquillian framework. So, we’ll be running our test right to a JBoss AS 5.1 managed by the testing framework.

The application we’ll use is quite simple. An EJB component that saves an employee to the database. It doesn’t use JPA so we get a chance to inject a datasource and use it to get a connection. You can download the code from here. Read the rest of this entry »