Embracing Jakarta EE 10 not only enable you to write better structured applications, it also enables you to write more testable applications. Correctly leveraging CDI enables integration testing where you can simulate a database error and verify that JMS messages are lost due to a RuntimeException. This session will focus on strategies and techniques for testing message handing, transaction management, security, and data model integrity. You will see how you can check message delivery and error handling, session failover, database versioning, and two-phase commits with JMS and databases. All too often assumptions are made that are proven wrong in production. This session will show you how to take your testing to the next level.

1. Integration Testing Strategies
& Techniques
Ryan Cuprak

2. Introduction
3ds.com
Ryan Cuprak
President Jakarta EE Ambassador
@jee_ambassadors
@rcuprak

3. Introduction
https://www.youtube.com/watch?reload=9&v=HiZLfOmH56U

4. Questions
slido.com
#GeeCON2022

5. Assertion
No platform other than Java has
better integration testing for server-
side applications.

6. Why is Jakarta EE Testable?
• Standardization:
• Deployment – configuration & structure (WAR)
• Runtime – containers (Tomcat, Payara, OpenLiberty, etc.)
• Resource Adapters (JDBC, RAR)
• Wells defined technologies (JAX-RS, JPA, JMS…)
• Rich vendor ecosystem
• Standardized build (Maven/Gradle)
Dependency Injection

7. Test Types
• Unit Tests
• Integration Tests
• Functional Tests
• End-to-End Tests
• Acceptance Testing
• Smoke Testing
Easily tested with Jakarta EE
* https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
Important to test more than happy
paths.

8. Test Platform

9. Arquillian
JBoss project:
• Tests written JUnit or TestNG
• Deploys/manages Java containers
Arquillian Modules:
1. Container Adapter
2. Test Enricher
3. Test Runner
4. Extensions
http://arquillian.org
Added as dependency
to Maven/Gradle
Shrinkwrap

10. Why Arquillian?
Arquillian deploys and runs container tests.

11. Arquillian Container Interaction
Remote – container resides in a separate JVM
Managed – container is remove but start/stop controlled
Embedded – resides inside same JVM
Different tests require different approaches!

12. Arquillian Run Modes
Where does the test run?
Embedded
• Test application internals
• Default mode – not annotation needed
External
• Test how application is used by clients ex. REST API
• JavaScript browser code
• Test web services, remote EJBs, etc.
• Tests annotated with @RunAsClient

13. Arquillian Test Enrichment
Injection
• @Resource – reference to any JNDI entry
• @EJB – Injects EJB, Local/Remote
• @Inject – CDI Beans
• @PersistenceContext – JPA persistence context
Contexts
• Request and conversation – test method
• Session – test class
• Application – test class
Used in the
tests!

14. ShrinkWrap
API for programmatically building artifacts
Eliminates system/script spaghetti
Artifacts can be test specific ex:
• Include/don’t include web services
• Exclude/replace initialization logic etc.
Supported archives types: JAR, WAR, EAR, RAR
https://github.com/shrinkwrap

15. ShrinkWrap API
ShrinkWrap class is the main entry point
Call ShrinkWrap.create() with one of the following:
• GenericArchive – simplest archive type
• JavaArchive – allows for addition of class/package, and manfiest
entries
• EnterpriseArchive - Java EAR type
• WebArchive - Java WAR type
• ResourceAdapterArchive – Java RAR type
WebArchive myArchive = ShrinkWrap.create(WebArchive.class,”app.jar");

16. ShrinkWrap – Adding Content
Sources of content
• Classpath, file, string, url, empty (placeholder), nested, archive,
byte array
War archive methods:
addClass()
addPackage()
addPackages()
addAsDirectories()
addAsWebInfResource()
addAsResource()
addAsLibraries()
addAsManifestResource()
addAsServiceProvider()
addAsWebResource();
- Shrinkwrap resolvers – Maven & Gradle

17. ShrinkWrap Example
Debugging:
Programmatically constructing a “war”:

18. Simple Example
Use Arquillian Test Runner
Inject a CDI Bean
Package Application
Test Application
“JUnit” integration test executes in a container

19. Container Dependencies

20. What can we do?
Arquillian + Shrinkwrap + JUnit
• Write JUnits that run in a container
• Write JUnits that call code in a container
• Inject CDI beans/EJBs/resources into a JUnit
• Programmatically construct an application (WAR)
• Programmatically generate or specify configuration files
• Include code from test class path
• Test pieces of an application

21. Integration Tests Setup
• Convention – end integration test in “IT”.
• Bind integration tests to Maven verify build phase.
• Profiles for embedded, remove, managed tests.

22. Integration Tests Setup

23. Remote Tests
Note: This test runs INSIDE of the remote container.

24. Extending Arquillian
• Testing often requires container setup
• JUnit supports the following:
• @BeforeClass @Before @After @AfterClass
• What about before deploy/undeploy?

25. Arquillian Container Extension

26. Arquillian Container Extension…
Allows actions to be performed before/after container deployments.

27. Leveraging Container Lifecycle
• Payara can be configured via command line.
• Register drivers, connectors, etc.
• Has a programmatic API for running commands (CommandRunner).
• Web configuration console can generate a script.
• More versatile and safer than hand crafted XML config files.

28. CDI
• CDI = Contexts and Dependency Injection
• Introduced in Java EE 6
• Type-safe dependency injection
• Well-defined life-cycle for stateful objects
• Integrated with Unified Expression Language (EL)
• Interceptors
• Events
• Extensible…

29. CDI & Testing
CDI simplifies testing:
• Mocking & error simulation using Alternatives
• Verification via events
• Spy on objects using interceptors

30. Mocking
Interface
Implementation
Mock

31. Mocking…
beans-alternative.xml

32. Leveraging Events

33. Leveraging Events…

34. Spying
Goal: Intercept and
inspect values

35. Spying…
• Is the interceptor enabled (controlled per test).
• Used to store capture value.

36. Spying…

37. Spying…
ebj-jar.xml – on text classpath

38. Spying…

39. Error Simulation
• Verify rollback is NOT
triggered.
• Even if in a try block, an
error will mark transaction
for rollback.
Saves to database

40. Error Simulation…
Intercepting this method

41. Error Simulation…
Alternative implementation
to throw error.

42. Error Simulation…
Deployment specifics bean.xml
enabling alternative of the DAO.
No error should be thrown,
but DaySummary should
not be update.

43. Testing persistence

44. Testing Persistence Challenges
• Data source configuration
• Database seeding & cleanup
• Change Verification
• Row ordering, ignoring columns

45. Arquillian Persistence Extension
• Arquillian Extension
• Leverages dbUnit
• Wraps each test in a separate transaction
• Seeds database
• XML, XLS, YAML, JSON, Custom SQL Scripts
• Compares database state - can exclude columns
http://arquillian.org/arquillian-extension-persistence/

46. Database Test Configuration
Can optionally provide a test specific persistence.xml file.

47. Database Test Configuration
payara-resources.xml
arquillian.xml
Both of these are on the test
classpath.

48. Database Test Example
requestedUser.yml expected-users.yml

49. Graceful Failure

50. JPA Caching
Does this test pass?

51. JPA Caching…
Test fails:

52. JPA Caching
Database
User A
User B
User C
Second Level
Cache
User A
User B
User C
Entity Manager 1
Entity Manager 1
User A
User C
User C
User B
Note: Default for cacheable is TRUE.

53. JPA Caching
Server A
Database
Entity Manger Cache
Server B
Entity Manger Cache
• Same caching issue arises in load balanced environment.
• Scale-up problems – simple environment works.

54. Testing Invalid Data

55. Testing Invalid Data…
Persistence.xml
JPA Bean Validation disabled in
Prod for performance.
Will this test succeed?
- NO -

56. Transactions & Tests
Goal: Test that purge works.

57. Transaction & Tests
Test doesn’t work!
What?

58. Transactions & Tests
ejb-jar.xml to the rescue!
• Add this test-only ejb-jar to archive using
shrinkit.
• The “purge” method will now be run in a
transaction.
THIS IS custom-
ejb.xml on the test
classpath.

59. Transactions & Tests

60. Testing JMS

61. Testing JMS
To test messaging code:
• Messaging service running
• App/web container configured for messaging
• Detect whether messages were read
• Detect whether messages entered DLQ
• Clean-up messaging system
• Avoid message theft

62. Testing Setup
1. Download ActiveMQ RAR
2. Start embedded ActiveMQ Broker
3. Start Container
4. Install ActiveMQ RAR
5. Configure Queues/Topics
6. Run Test
7. Clear queues/topics for next test

63. Retrieve ActiveMQ RAR
Simple download and cache.

64. Start Embedded Broker
Custom utility class leveraging ActiveMQ API.
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-broker</artifactId>
<version>5.17.2</version>
<scope>test</scope>
</dependency>

65. Configure Embedded Payara
Deploys RAR and registers queues.

66. Test Setup Code

67. Simple JMS Test
Verify Queue is Empty.

68. Broker Services Utility
Custom utility wrapping ActiveMQ
APIs to extract data.

69. Testing Poison Pill Message
• Server expects a JSON message, we are sending it invalid data.
• Message should be dumped into the DLQ - not vanish.

70. Additional Testing
• Test configuration of MDB pool versus database pools.
• Verify message delivery – pre-fetching
• Test throughput to identify bottlenecks
• Verify failures don’t cascade
• Verify an MDB isn’t corrupted (state kept)

71. Testing Security

72. Application Security
• EJB Security
• Who can trigger business logic
• Database Security
• Insert/update/select permissions
• Web Security
• Basic/Form base security
Web Security
EJB
Database

73. Role Based Testing
----------------
Test will fail with
security exception.

74. Role Based Testing
Create a proxy to run the test!
Note- This is an EJB only on the test classpath!

75. Role Based Test
• Proxy runs the test with the correct role.
• Create a proxy for every role.

76. Role Based Testing
Gotcha – tests will still fail!
admin
Need to configure the embedded container!

77. Role Based Testing
WEB-INF/payara-web.xml
Note mapping to defaultAdmin &
defaultMember

78. Role Based Testing
• Configure the embedded container in beforeDeploy()
• Now roles in the app map to a configured role in the container.

79. Account Testing
• Proxy solves the problem of running with a role.
• Problem, what about the current user session?

80. Account Testing…
Add a web service for which the container populate principal.

81. Account Testing…
Custom web.xml for test that
enables basic authentication

82. Accounting Testing…
This is one strategy for testing with a populated
principal.

83. Entity Managers
admin member guest
Entity Manager
Database sec_admin_user sec_guest_user
sec_member_user

84. Entity Manager Verification
Built-in Check
Integration Test

85. Strategies
• Arqullian rules!
• Leverage CDI to reduce coupling and enable testing
• Break application into testable blocks
• Split tests into remote and embedded
• One test class per test configuration
• XML config file
• Classes
• Use Interceptors where instrumented classes (Mockito
Spies) cannot be used.

86. Gotchas
• Transaction testing can be tricky.
• Simulating exceptions may not generate expected
rollback.
• MDBs are asynchronous – how long to wait?
• Security testing can be divided into testing roles and
data access via current user.

87. Integration Testing Suggestions
• Testing different application container versions
• Check if a point release will have any change
• “Easily” verify if another container is feasible
• Check impact of newer Java version.
• Test sporadic errors/failures
• Database down
• Multiple concurrent messages
• Bad data load (data dump loaded without Bean Validation)

88. Summary
Server-side Java can be
Tested!

89. Q&A
Twitter: @ctjava
Email: rcuprak@gmail.com / r5k@3ds.com
Blog: cuprak.info
Linkedin: www.linkedin.com/in/rcuprak
Slides: www.slideshare.net/rcuprak/presentations