As Arquillian has become steady at the programmer’s tool belt, its action scope has entered debate as some feel it’s an integration testing specific tool and some others see it as the long awaited tool which will bring end to end testing as the only testing a programmer needs from now on. The latter is the motivation of this post as it forgets about the power of unit testing and might not see that Arquillian’s purpose may change depending on the extension you use. Continue reading
Tag Archives: arquillian
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. Continue reading
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.
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.