Testing secured EJBs has been historically hard to get right. Up until now, I have been using proprietary techniques like JBossLoginContextFactory described in the article Testing secured EJBs on WildFly 8.1.x with Arquillian to test secured EJBs.
During this year Devoxx, David Blevins, founder of the Apache TomEE project – a lightweight Java EE Application Server, brought to my knowledge a little trick we can use to deal with Java EE security in a standard way that works across all Java EE compliant servers.
The example used in this post is available at javaee-testing/security on GitHub.
Continue reading Testing secured EJBs with Arquillian
In Java EE 6 Testing Part I I briefly introduced the EJB 3.1 Embeddable API using Glassfish embedded container to demonstrate how to start the container, lookup a bean in the project classpath and run a very simple integration test.
This post focus on Arquillian and ShrinkWrap and why they are awesome tools for integration testing of enterprise Java applications.
The source code used for this post is available on GitHub under the folder
Arquillian brings test execution to the target runtime, alleviating the burden on the developer of managing the runtime from within the test or project build. To invert this control, Arquillian wraps a lifecycle around test execution that does the following:
- Manages the lifecycle of one or more containers
- Bundles the test case, dependent classes and resources as ShrinkWrap archives
- Deploys the archives to the containers
- Enriches the test case with dependency injection and other declarative services
- Executes the tests inside (or against) the containers
- Returns the results to the test runner for reporting
ShrinkWrap, a central component of Arquillian, provides a simple mechanism to assemble archives like JARs, WARs, and EARs with a friendly, fluent API.
One of the major benefits of using Arquillian is that you run the tests in a remote container (i.e. application server). That means you’ll be testing the real deal. No mocks. Not even embedded runtimes!
The following topics will be covered on this post:
- Configure the Arquillian infrastructure in a Maven-based Java project
- Inject EJBs and Managed Beans (CDI) directly in test instances
- Test Java Persistence API (JPA) layer
- Run Arquillian in client mode
- Run and debug Arquillian tests inside your IDE
Continue reading Java EE 6 Testing Part II – Introduction to Arquillian and ShrinkWrap
One of the most common requests we hear from Enterprise JavaBeans developers is for improved unit/integration testing support.
EJB 3.1 Specification introduced the EJB 3.1 Embeddable API for executing EJB components within a Java SE environment.
Unlike traditional Java EE server-based execution, embeddable usage allows client code and its corresponding enterprise beans to run within the same JVM and class loader. This provides better support for testing, offline processing (e.g. batch), and the use of the EJB programming model in desktop applications.
The embeddable EJB container provides a managed environment with support for the same basic services that exist within a Java EE runtime: injection, access to a component environment, container-managed transactions, etc. In general, enterprise bean components are unaware of the kind of managed environment in which they are running. This allows maximum reusability of enterprise components across a wide range of testing and deployment scenarios without significant rework.
Continue reading Java EE 6 Testing Part I – EJB 3.1 Embeddable API
My previous Maven 2 Cobertura Plugin article gives a workaround for the very buggy version 2.1 of the Cobertura Maven Plugin.
This bug is fixed on versions 2.2 or higher, and consequently, that workaround does not work anymore.
For those reading my previous article and having difficulties configuring the plugin, this is my actual configuration.
Continue reading Maven 2 Cobertura Plugin – Updated
The JBoss Microcontainer is a refactoring of JBoss’s JMX Microkernel to support direct POJO deployment and standalone use outside the JBoss application server.
It allows the creation of services using simple Plain Old Java Objects (POJOs) to be deployed into a standard Java SE runtime environment.
JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located.
The goal of this article is to show how easy it is to test these services using TestNG testing framework.
Continue reading Unit Testing JBoss 5 Services
No matter how anxiously expected, the release of IE8 hasn’t resulted in the end of the support for the old, deprecated, IE6 rendering engine. Giving us, the web developers, need to test against yet another version of IE.
Hopefully the eighth version is going to be a lot easier to test and support since it’s more standards compliant and in that perspective, much closer to the other modern browsers. It’s also comes with easier debugging functionality as it has an integrated set of developer tools available by pressing F12 or by clicking ‘Developer Tools’ under Tools menu.
But right now, together with other major players (Firefox, Opera, Safari and Chrome) you can end up with a total of 7 browsers to test. You might even want to test different versions of individual browsers, transforming this task into a nightmare. Fortunately tools, allowing you to compare different rendering engines in a single unified interface, are emerging and can really save the day. Two great examples are:
- Microsoft Expression Web SuperPreview
- DebugBar IETester
For a complete list of browser’s compatibility, check the great Compatibility Master Table from QuirksMode.
The Maven 2 Cobertura Plugin web site lacks information to successfully generate Cobertura reports. Worse, some of the usage examples are incorrect and don’t work.
The most common problem when generating Cobertura reports is when the generated report shows 100% test coverage while in reality many of the classes don’t even have tests.
The following example shows how to configure the reports so that it would reflect real test coverage and then check if the specified packages achieved the wanted test coverage: