Service oriented architectures can help to break a large, unwieldy application into a federation of smaller, more manageable, and more reusable services. Unfortunately, these architectures can dramatically increase the complexity of testing, and can turn the process of release qualification into a chaotic mess. In this inaugural TriTAUG lecture, we'll discuss some of the challenges inherent in testing SOA based systems, and provide some practical suggestions on how you can get your release testing and qualification process back under control. About the speaker: Tom DeWire is a Software Architect for Bronto Software in Durham, NC. Prior to his current role, he was a 14 year veteran of the video game industry, having worked at Electronic Arts during most of his tenure. During that time, he focused on the increasingly complex and high-scale services required to support the ever growing demand for more, and more engaging online gaming experiences. He attended the University of Virginia, where he received a B.A. in Environmental Science. When not thinking about software, he can usually be found on his porch, plunking away on his banjo.

1. Testing Challenges in
Service Oriented
Architectures
TriTAUG 3/13/2013

2. What is SOA?
Reasonable people can disagree...

3. What is SOA?
Is it this?

4. What is SOA?
Or this?

5. What is SOA?
Or this?

6. What is SOA?
Maybe this?

7. What is SOA?

8. What is SOA?
The guiding principles.
Behaviors are built via: Services are built with:
● Contract ● Abstraction
● Discovery ● Autonomy
● Composition ● Decoupling
● Reuse ● Statelessness

9. What is SOA?
SOA is a set of guiding principles that can help
you decompose a complex, monolithic
application into an application composed of
discrete, distributed services.
SOA allows you to more easily scale your
application to meet demand.
SOA allows you to more easily scale your
engineering team to meet demand.

10. Why is testing SOA hard?
Let's take a little stroll...

11. The "Good" Old Days

12. n-Tier the Dragon

13. Sanity Ousting
Architecture?

14. Why is Testing SOA Hard?
● So many services
○ ... most are headless
○ ... most have independent lifecycles
○ ... with so many interactions between them
○ ... with so many failure domains
● So many teams
○ ...some working on shared libraries
○ ...some working on discrete services
○ ...some composing new application behaviors
● So many moving parts
○ ...more changes than you can possibly follow
○ ...more builds than you can possibly verify

16. Layering Tests
● Unit Tests
○ Tests the smallest behaviors exposed by source
○ No external dependencies
● Integration Tests
○ Tests the smallest behaviors exposed by a service
○ Minimal external dependencies
● Acceptance Tests
○ Tests the entire, fully composed application
○ The kitchen sink -- every service, every resource

17. Layering Tests
● Unit Tests
○ White Box
○ Immediate feedback
● Integration Tests
○ Grey Box
○ Validating behavior against service specification
● Acceptance Tests
○ Black Box
○ Validating behavior of the complete application

18. Build a Funnel
? ? ? ? ?
...that pass unit tests
...that pass integration tests
...that pass acceptance tests
!

19. Let Computers Do The
Heavy Lifting
M'lord...
Your pre-verified
build is ready.

21. Change Assumptions &
Stop Swimming Upstream

23. Testing Challenges in
Service Oriented
Architectures
TriTAUG 3/13/2013