Sei sulla pagina 1di 29

Best Practices for the testing of SOA-based

systems –
with examples of Oracle SOA Suite 11g

DOAG conference 2009

Guido Schmutz,
Technology Manager / Partner
Trivadis AG

18.11.2009, Nürnberg

Basel · Baden · Bern · Lausanne · Zürich · Düsseldorf · Frankfurt/M. · Freiburg i. Br. · Hamburg · München · Stuttgart · Wien
Introduction

 Guido Schmutz
 Working for Trivadis for more than 12 years
 Oracle Ace Director for Fusion Middleware and SOA
 Co-Author of different books
 Consultant, Trainer Software Architect for Java, Oracle, SOA
and EDA
 Member of Trivadis Architecture Board
 Trivadis Technology Manager

 More than 20 years of software development experience

 Contact: guido.schmutz@trivadis.com

Best Practices for the testing of SOA-based systems © 2009


About Trivadis
 Swiss IT consulting company

 13 locations in Switzerland,
Germany and Austria

 ~ 540 employees

 Key figures 2008

 Services for more than 650 clients in


over 1‘600 projects

 Over 150 service level agreements

 More than 5‘000 training participants

 Research and development budget:


CHF 6.0 Mio. / EUR 3.6 Mio.

3 © 2009
Agenda

 Introduction

 Scenario with SOA Suite 11g as an example

 Unit Testing of SOA Suite 11g components

 Integration Testing of SOA Suite 11g


composites
Data are always
part of the game.  Summary

Best Practices for the testing of SOA-based systems © 2009


Testing of SOA solutions
 For testing N-tier solutions some common best practices have been
established
 Unit and Integration Tests
 Test Driven Development / Test-First Approach
 Mock Objects

 A lot of these approaches can be used/adapted for testing SOA solutions as


well

 Testing a SOA solution is as important


 Often enterprise wide systems (backbone of an enterpirse)
 Many different users
 Each single error can have a huge impact

 Even if in a SOA a lot of existing functionality is used, it’s not enough to just
test these
 SOA adds some additional logic via Router, Filter, Orchestration, which has to be
tested as well

Best Practices for the testing of SOA-based systems © 2009


Challenges for testing a SOA solution

 SOA environments are inherently heterogeneous

 SOA solutions typically integrate a set of packaged or custom


applications

 It may not be possible to re-create a dedicated testing environment for


all the systems involved

 Tests are usually carried out in a synchronous way, SOA often works
asynchronously!

 Business processes often depend on timed events

 Minimal unit of test in a SOA tends to be larger and more data driven
than in traditional applications

 Testing tools for SOA solutions are not yet readily


Best Practices for the testing of SOA-based systems © 2009
Automatic Testing

 Relies on automatic, programmatic execution of the different test


scenarios

 The results can be verified against expected results

 Efficient development and execution of test cases can only be


achieved with the help of Testing Frameworks

 A Testing Framework provides some common, reusable


components, which supports the creation and execution of test
cases as well as the verification of test results.

Best Practices for the testing of SOA-based systems © 2009


Functionalities of a Test Framework

 Generator
 Produces the test data and with it calls the components under test

 Verifier/Asserter
 Compares the actual test results with the expected results
 It’s important that a Verifier/Asserter makes an accurate, binary decision whether a
test was successful or not

 Mock/Stub
 Testing component that simulates part of the system that is not under test

Best Practices for the testing of SOA-based systems © 2009


Unit / Component Testing

 Focuses on a specific component in the system

 Outside dependencies must be isolated as much as possible to assure


that the component can be tested in isolation

 Easier to achieve with low-level component, which have none or almost


no dependencies

 Integration issues between components may not be discovered


G V
 Ensures that when integration
begins we can have
confidence in the functionality BPEL G V BPEL
of each component being
integrated Mediator / Mediator /
G V M
ESB ESB

Best Practices for the testing of SOA-based systems Service Service M


© 2009
Integration Testing

 Focuses on the interaction between multiple components

 Focuses on the lower layers first


 Because they have the least external dependencies

 If an integration test fails in the upper layers, its unlikely that the reason
is a faulty lower layer component since these components have already
been tested
G V
 Also referred to as
Bottom-Up Testing
BPEL G V BPEL

Mediator / Mediator / Mediator /


G V
ESB ESB ESB

Service Service Service Service


Best Practices for the testing of SOA-based systems © 2009
Agenda

 Introduction

 Scenario with SOA Suite 11g as an


example

 Unit Testing of SOA Suite 11g


components
Data are always
part of the game.  Integration Testing of SOA Suite 11g
composites

 Summary

Best Practices for the testing of SOA-based systems © 2009


Sample scenario

Internally

Request

Generate ID

Read customer info

Validate credit card

Externally

Best Practices for the testing of SOA-based systems © 2009


Implementation with SOA Suite 11g

 SCA composite once for the process with the connection to the
customer system and once for the credit card validation
 First SCA composite is called from the second

 Credit card validation implemented as Mediator service


 Decides which credit card institute to be called

 Business Process implemented through BPEL component

Best Practices for the testing of SOA-based systems © 2009


Agenda

 Introduction

 Scenario with SOA Suite 11g as an example

 Unit Testing of SOA Suite 11g components

 Integration Testing of SOA Suite 11g


composites
Data are always
part of the game.  Summary

Best Practices for the testing of SOA-based systems © 2009


G V

Unit testing of a Mediator 11g component Mediator /


ESB

 In order to be able to test a Mediator component isolated (as a


M
unit) there must be a way to simulate the two service references
(Visa and Amexco)

 This way it can be tested, that the Routing and Transformation


logic in the Mediator works correctly

 This can be achieved


with the SOA Suite
Unit Testing Framework
 Services can be simulated
 Results can be verified

Best Practices for the testing of SOA-based systems © 2009


Unit testing of a Mediator 11g component

 Oracle SOA Suite 11g provides a testing framework with the


following features
 Definition of tests, assertions and emulations via JDeveloper
 Starting Tests from the EM console or via the command line using
ANT
 Test Reports via EM console or via JUnit report

 A test case contains


 Initiation
 Defines the services and operations, which will be called with test data
 Emulation
 Defined the message or error, which will be returned from a reference or a
component
 Assertion
 Compares the message or part of the message against expected data

Best Practices for the testing of SOA-based systems © 2009


Initial message, will be Given answer for the
sent to the generator Visa service, without
component (Generator) calling the real service
(Mock)

Answer will be
tested against
the expected
message
(Verifier)

Best Practices for the testing of SOA-based systems © 2009


G V

Unit testing of a 11g BPEL component BPEL

 CustomerMediator will be called, but the database access M

(via DB-Adapter) will only be simulated

 Answer of CreditCardService will only be simulated

 Allocation of the booking ID will only be simulated


 Fixed and deterministic values
are always returned
 Important to be able to test
the answer with an
Asserter (Verifier) against
an expected message

Best Practices for the testing of SOA-based systems © 2009


Deployment of test cases

 Test cases will be


deployed with the
normal deployment
of an SCA composite

 Unit tests can be


executed via
Enterprise Manager
(EM) console

Best Practices for the testing of SOA-based systems © 2009


Agenda

 Introduction

 Scenario with SOA Suite 11g as an example

 Unit Testing of SOA Suite 11g components

 Integration Testing of SOA Suite 11g


composites
Data are always
part of the game.  Summary

Best Practices for the testing of SOA-based systems © 2009


Integration Testing of SOA solutions

 After the isolated testing of each single component, we can be sure, that
these work correctly by itself

 Now we also want to test them integrated

 Each single components are deployed together against the testing


environment and connected with the corresponding test versions of the
external services

 What should we do, if there is no test version available of a given


service?

 What should we do, if the service is not available at all?

Best Practices for the testing of SOA-based systems © 2009


Integration Testing of SOA solutions

 How can the behavior of an external service can be influenced?


 So that all the different possibilities can be tested
 To be able to test the behavior of a SOA solution in an error case, the error
situation has to actually happen

 How does somebody bring an (external) service to produce an error at


the right moment?

 The soluiton is again a Mock Service, which takes over the place of the
external services G V

BPEL

Mediator /
ESB

M
Best Practices for the testing of SOA-based systems © 2009
But how to I get these Mock Services?

 How should we implement Mock Services?

 The previously shown Unit Testing Framework of SOA Suite 11g


is not available in the integration environment

 Should we start implementing the Mock Services as own web


services with the language of our choice, in such a was, that they
can achieve the requirements mentioned before?

 One advantage of SOA is the standardized description of the


interfaces through the WSDL
 There are more and more utilities/tools, which uses such a WSDL as
the starting point to simplify some of the tasks within a SOA solution

Best Practices for the testing of SOA-based systems © 2009


soapUI http://www.soapui.org/

 Utility for the testing of a SOA

 Available in a free version

 Supports the Testing of SOAP as well as REST webservices

 Covers these functionalities:


 Inspection and call of web services
 Functional testing of web services
 Load testing of web services
 Creation of Webservice-Dummies (Mock Services)

Best Practices for the testing of SOA-based systems © 2009


Mock Service for the Visa Service

Best Practices for the testing of SOA-based systems © 2009


Testing a Webservice with soapUI

Best Practices for the testing of SOA-based systems © 2009


Agenda

 Introduction

 Scenario with SOA Suite 11g as an example

 Unit Testing of SOA Suite 11g components

 Integration Testing of SOA Suite 11g composites

 Summary

Data are always


part of the game.

Best Practices for the testing of SOA-based systems © 2009


Summary

 Best Practices for testing conventional applications are valid for


SOA solutions as well

 Unit Testing of SCA components is well supported via the SOA


Suite 11g testing framework
 Not complete yet, but already quite usable

 Integration Testing can be implemented with soapUI, a well-


known utility available in a free version
 calling a SOA Suite Services
 Creating a Mock Service for an external service
 soapUI is much more powerful than shown here

 All the Tests shown can be automated

Best Practices for the testing of SOA-based systems © 2009


Thank you!

DOAG conference 2009

Guido Schmutz,
Technology Manager / Partner
Trivadis AG

18.11.2009, Nürnberg

Basel · Baden · Bern · Lausanne · Zürich · Düsseldorf · Frankfurt/M. · Freiburg i. Br. · Hamburg · München · Stuttgart · Wien

Potrebbero piacerti anche