Using NetBeans for Arquillian integration testing
Running Arquillian integration tests in NetBeans gives Java code a realistic Jakarta EE runtime without a shared staging server. The test starts a container, deploys a small archive, injects enterprise components, and verifies behaviour through the application's real interfaces.
This suits teams in Sydney, Melbourne, Brisbane and Perth that need repeatable checks before deployment. It also keeps the command line central, which helps when a train connection drops during the commute or a defect must be reproduced outside office hours.
Why container-based integration tests matter
An integration test exercises cooperation between components, so mocks alone cannot reveal a descriptor problem, a missing CDI bean or an unavailable message broker. A managed Arquillian container provides the runtime while the test controls deployment and cleanup.
NetBeans offers Maven execution, source navigation and debugging around that workflow. Its NetBeans background explains how the IDE's Java EE support evolved, which is useful when teams combine an older sample with a current Jakarta project.
Match the Arquillian adapter, application server and Jakarta EE generation. Code importing jakarta.ejb.* must not be tested against a server expecting only javax.*; likewise, the JUnit version determines which Arquillian test adapter you need.
Preparing the project and dependencies
Create a dedicated Maven module, or a separate profile in an existing one. Include the Arquillian JUnit adapter and matching managed-container adapter in test scope. Declare Jakarta EE API dependencies as provided when the container supplies them, and keep server implementations out of the production archive.
Point JAVA_HOME at the JDK required by the chosen server, then confirm that NetBeans uses the same JDK. For an *IT class bound to Maven Failsafe, run the verify lifecycle through NetBeans' Maven goal output rather than treating it as an isolated unit test.
Building a deployable test archive
Build a ShrinkWrap JavaArchive containing the EJB or CDI classes, required resources and an empty beans.xml when implicit bean discovery is enough. Use Maven resolution with transitive dependencies; assembling classes by hand often omits an annotation or provider that fails only at deployment.
Deploy the archive with @Deployment, run it under the Arquillian JUnit runner and inject components with @EJB or @Inject. Arquillian enriches the archive, starts the managed server and runs the test inside the container, so an empty database or unmapped request has realistic behaviour.
For an HTTP-only boundary, use @Deployment(testable = false) and call the deployed endpoint from the test. This keeps the client path outside the server while still verifying deployment, routing and serialisation.
JMS paths need special care. The site's message-driven bean overview explains the listener boundary; test message delivery and rollback separately, because successful archive deployment does not prove that the broker routed or redelivered a message.
Comparing application server choices
Choose the server from the features under test rather than from a generic Java EE label. The practical differences are:
| Container | Best fit | Managed Arquillian adapter | Watch for |
|---|---|---|---|
| WildFly | Full Jakarta EE work involving EJB, CDI, JAX-RS or JMS | arquillian-container-wildfly-managed |
Match server modules and the JDK to the project |
| Open Liberty | Jakarta EE suites with the required features installed | arquillian-container-liberty-managed |
EJB, CDI and messaging features must be present |
| Apache Tomcat | Servlet, JSP and HTTP-level JAX-RS checks | arquillian-container-tomcat-managed |
It is not a complete EJB or CDI runtime |
In the Australian market, compare the zero licence cost of WildFly with paid support and hosting for commercial platforms, whose quotes commonly use Australian dollars. Include training and CI runner capacity; a cheap local server can become costly when failures consume the team's afternoon.
Network binding deserves a separate check. Australian internet providers have widely deployed IPv6, and a container listening only on IPv4 may behave differently from one expecting dual-stack access. The compatibility lessons in IPv6 DenyHosts guidance reinforce the need to test resolution, firewall rules and both address families rather than assuming localhost is equivalent.
Configuring managed execution and test data
A managed adapter launches the server on the same workstation and is usually the simplest choice. A remote adapter is useful for shared environments, but it needs reachable management ports and credentials; do not expose an unauthenticated management interface to the public internet.
Timer-based behaviour deserves its own boundary check. A scheduled session bean from the site's timer service example can be tested with a programmatic EJB timer for speed, while one slower run verifies the scheduler, transaction boundaries and clock configuration.
These managed execution settings prevent common local failures:
- Align the JDK, server distribution and Arquillian adapter versions.
- Reserve unused HTTP and management ports for parallel builds.
- Give each developer a separate container data directory.
- Keep credentials in environment variables, not source control.
These checks also protect test data and repeatability:
- Use synthetic identities, records and account numbers.
- Confirm the archive contains
beans.xml, resources and providers. - Capture container logs alongside Surefire or Failsafe reports.
- Run the same archive against the CI container image.
Diagnosing failures with reproducible evidence
Read failures in layers: archive creation, deployment, injection and application logic. A ClassNotFoundException often points to missing archive content, while a timeout may indicate a blocked management port or a server waiting for a dependency. Separate those signals before changing application code.
Keep test data synthetic and record only what the scenario requires. The checklist analogy in toddler doctor preparation is useful here: a short, focused set of facts prevents confusion. Australian teams must also follow the Australian Privacy Principles and the Privacy Act 1988 whenever real personal information enters a covered organisation's development or CI environment.
A useful run record contains the exact Maven command, Java version, Arquillian adapter, container version and deployment log. A screenshot of a red marker in NetBeans loses the context needed to distinguish a packaging error from server configuration. Preserving those details makes another attempt faster and the eventual fix traceable.