The document discusses challenges with testing Java EE applications and introduces Arquillian as a framework that aims to make testing easier. It provides flexibility through pluggable components, allows testing directly from IDEs, and abstracts server lifecycles. Key features include bundling test dependencies without repackaging, injecting resources into tests, and supporting various containers and test frameworks.
2. Java EE Development Evolution POJO Model Container Services Ease of Development Ease of Testing Framework Integration Dependency Injection JNDI CMP EJB2.x Struts Hibernate EJB3 JPA JSF CDI Weld Spring Arquillian Seam “Lightweight” movement Grails
3. Shift Focus to Testing in EE Lots of developers abandoned EE in search of greener “testing” pastures. Testing has not been the focus for most of the platform’s history. Ride the wave… encourage support and adoption Dev-friendly container-based component models cry out for ease of testability!
4. Real EE Testing What does “real” mean? Unit testing using doubles can only get us so far when working with container managed resources. Want to be confident we get the interactions correct between container managed resources Short feedback cycle when making a change
6. Rolling Your Own How do I get unit test class into the container? Remote deployment (using hook into server) Bootstrap container inside test How do I exercise the code under test? How do I see the results of the test? How does test isolation work? Test classpath-hell Can I call it from IDE and get results?
7. Challenges to testing in container High barrier to entry Substantial code, configuration and infrastructure Most don’t run from IDE - where’s the feedback? Most aren’t reusable – tied to 1 project’s build Often slow (think “mvn package”) Can’t interact with containers from test (all black-box testing) Enough ROI to justify work/maintenance?
8. CDI (JSR-299) TCK + ALR EJB3 book examples Used by Weld Plan to be used by JBossAS “Ike” - controls everything in his little world Good way to learn CDI, EJB, JPA, etc.
9. Arquillian Features JUnit or TestNG compatible Abstracts out server lifecycle and deployment Injects container managed resources into test Zero reliance on build – run straight from IDE Two container modes – remote/embedded Pass-by-reference between test and server Even across JVMs Extensible SPI to plug any container in Single test executed against all containers
11. Arquillian: Flexibility Out of the box, supports multiple: Test frameworks (JUnit, TestNG) Containers Enrichers Run Modes Most things are pluggable API/SPI Modular design
12. ShrinkWrap “Skip the Build!” Fluent API for describing deployable archives Apache-licensed Zero transitive-dependency promise Solves test-classpath madness Removes dependency of integration tests on packaging Creates fine grained archives Contains only what you need
14. ShrinkWrap IDE can perform incremental compilation Change a class that is ShrinkWrap’d, only that class needs to be recompiled (no repackaging) Poor man’s “hot swap”? Future support tooling views in IDEs See what your archive would look like when SW is executed
15. ShrinkWrap – Arquillian Integration Simple – method annotated @Deployable within your test class Gets called by ShrinkWrap when deploying your archive, “bundles it” on the fly
16. Containers Loosely defined, anything that accepts an archive deployment and provides services Arquillian finds specified DeployableContainer SPI on classpath Multiple containers already supported, fairly easy to add support for a container Configured by using Maven profiles, e.g. mvn test –Pjbossas-remote-6
17. Container Modes Describes how the test archive should be deployed Embedded Same JVM Bootstraps container, often “standalone” environment Managed Different JVM, same machine Server will be started/stopped as part of the test run Remote Different JVM, different machine Server startup/shutdown not controlled by ARQ Arquillian controls binding/unbinding to server
18.
19. Container Support Notably, no Weblogic and no WebSphere yet Looking for community contribution No Spring or Hibernate yet, but they’re planned.
20. Enrichers Allow for injections into your test from within a container Out of the box, supports: @Resource (ghetto!) @EJB (a few caveats) @Inject (CDI) Transparent to user – internal lifecycle step before executing test methods
21. Run Modes IN_CONTAINER AS_CLIENT Arquillian uses this when running your test (after enrichment) Determines which side of the client/server divide the test method should be executed on See LocalRunServletTestCase
22. Embedded Lifecycle Bundle test archive* Use ShrinkWrap’d archive Bootstrap container Deploy archive to container Enrich test class Execute tests After execution, undeploy archive Stop container Display captured test results
23. Managed Lifecycle Bundle test archive* Use ShrinkWrap’d archive Add test class and invoker Bootstrap server Deploy archive to container Enrich test class Negotiate test method execution (based on Run Mode) Collect test results, return back thru Arquillian After execution, undeploy archive Stop server Display test results returned from server
24. Remote Lifecycle Bundle test archive* Use ShrinkWrap’d archive Add test class and invoker Bind to container Deploy archive to container Inside container, enrich test class Negotiate test method execution (based on Run Mode) Collect test results, return back thru Arquillian After execution, undeploy archive Unbind from container Display test results returned from server
27. The Cons Lack of true test isolation Implementing feature to deal with isolation If using an Embedded container you’re in a “Simulated” environment Easy to turn an embedded test into a remote test
28. The Pros Scale up to the level of integration you need by growing your test archive Rely on shared memory Don’t have to return/serialize a lot of state just to do asserts on Pass-by-reference works Don’t need remote views exposed just to test Managed concurrency Multiple containers for free
29. Future *Bundling – read Maven pom.xml and run through dependency resolution algorithm to include required dependencies Support for more Containers Performance monitoring Archive “bundle-time” class manipulation Exception, Callback, Assertion injection Component coverage recording Tooling support Framework integration Selenium, HTTPUnit, DBUnit, easyB
30. #jbosstesting initiatives Establish testing culture in Java EE! Other frameworks Placeebo – Mock Java EE API implementations (Fakes) JSFUnit – Gray-box JSF testing (Pretty cool, if you’ve seen SeamTest in action)
31. Further Info Chris Wash, @cwash (Twitter, Yammer) Use #testrevolutionhashtag Material jacked from the following sites: http://github.com/arquillian/arquillian-showcase http://www.slideshare.net/mojavelinux/real-javaeetestingwithanswers http://docs.jboss.org/arquillian/reference/latest/en-US/html_single IRC #jbosstestingirc.freenode.net Sites http://jboss.org/arquillian http://jboss.org/shrinkwrap Source http://github.com/arquillian
Notes de l'éditeur
We branched from Grails developers as we began to walk upright.
“Unit testing doesn’t catch the kind of bugs I write.”Test doubles – unit testing constructs that help provide test isolation. Fakes – empty impls make setup of test easier, like Spring test helpers. Stubs – simpler implementation for testing, like a dummy Paypalwebservice.Mocks – allow you to test interactions between collaborating objects.
Without Arquillian…
Classpath for the test has traditionally been a kitchen sink of all production classes and resources with the test classes and resources layered on top. Can make the test run undeterministic, different from what actually happens, hard to isolate different resources. One big reason to use SW – microdeployments – contain only what you need!
