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
Category Archives: tools
This very short post is to share with you a spike I’m taking on the JDK7: Project Coin. You can have access to the code at git://github.com/iapazmino/java7-tour.git.
For more than a few definitions on a spike, take a look at this discussion on stackoverflow.
Notice how you only need some tests to learn something new.
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
Every time you code and promise you’ll eliminate duplicated code later, replace System.out.println with a proper logger tomorrow, refactor that 15-options-if before the weekend you get into a debt you can’t pay. Even worst, your already big debt gets bigger. So, there are not more loans for you. Here’s a code auditing profile to be run in every build. Continue reading
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. Continue reading
At work, with about a hundred applications running, have started a mavenizing project. Diversity is a rule when it comes to used technologies and techniques in the building of those systems, but I’ll try to expose a common scenario: an old plain ejb2 project that uses XDoclet to generate interfaces code.
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.