Throwing complexity over the wall, easy in-container testing, Shrinkwrap and Arquillian, Andrew Rubinger

JBossWorld Boston, Andrew Lee Rubinger, Throwing complexity over the wall

What is important to employer
– bottom line
– features
– time-to-delivery
– implicit assumption that everything is of high quality
– not much tolerance for refactoring, stress-testing,…

Software can be in three silos
– core concerns : business logic, domain specific, no one else can do this ; time spent here is a good investment
– cross cutting concerns : independent of business logic, targeted, composable, “aspects”/”advice”, orthogonal/perpendicular
– plumbing : get data from A to B, transformation, does (should) not affect state, enables loose coupling, generic, usually implemented by frameworks ; typically not the best use of an application developers time

What should you do
– business logic, core concerns
leave the rest to servers and frameworks
– less you write, less you need to maintain

Components model as solution
– run in a “container”
– container manages the environment, wires up at runtime
– user code executes as deployable components
– components follow a standard form, or model

And what is Jave EE
– collection of specifications which allow writing business logic as components
— recipe to write less
— increase signal to noise ration
– platform defining how containers should handle this

What’s missing?
– a cohesive way to develop and test our applications
– applying the same component model to out tests

Importance of testing – the often ignored
– forces developers to be users
– key in proving API design makes sense
– self-documenting
– gives a sustainable path forward
– slims the release process, no big-bang runs at the end

Excuses, excuses
– testing is not enjoyable, it should be!
– when under pressure to deliver, test code does not deliver bottom-line

Unit testing
– finely grained
– speed is important

Integration testing
– coarsely grained
– component interactions
– agile “user stories”

Traditional approach to integration testing
– start container
– do test using some kind of remoting
– clean up the house

In-JVM embedded integration testing
Pro
– shared memory
– pass-in-reference
– no remotable views
– manage concurrency
Cons
– lack of isolation
– JVM start-up parameters may differ

Hybrid approach
– container in its own process
– test is deployed as archive, bundled alongside test execution framework
– test runs inside container
– TestRunner obtains the results remotely

Test reliance upon the build
– adds extra step to the development/test cycle
– packaging : defines a unit, regulates class loading

Fake the environment for unit tests
– use mock objects, stub out API which may not be available, gets you running in POJO environment

Introducing ShrinkWrap
– simple mechanism to assemble archives like JAR, WAR, EAR in Java
– deploy “virtual” archive in container, integrates with JBoss EmbeddedAS, OpenEJB, Jetty, GlassFish v3

Micro deployments
– Using ShrinkWrap to deploy components in isolation
– test one thing at a time

Arquillian
– provide simple test harness to produce braod set of integration tests for (enterprise) Java applications
– abstract our server lifecycle

How
– use “@RunWith(Arquillian.class)”, define the deployment (annotated with “@Deployment”)
– rest are just your tests and some annotations to wire everything up
– container is not defined in the test class, can be defined separately

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*