Service-Oriented Architecture Testing Design and Practices

Transcription

1 Service-Oriented Architecture Testing Design and Practices Alexandre A. dos Santos Júnior André Elia Assad Luiz Felipe S. L. Guimarães C.E.S.A.R / Motorola C.E.S.A.R / Motorola C.E.S.A.R / Motorola Alexandre.Junior@cesar.org.br Andre.Assad@cesar.org.br Luiz.Guimaraes@cesar.org.br Abstract Testing is an indispensable part of software development, and the testing techniques must keep always evolving to address the new behaviors of software applications. The procedural and object-oriented paradigms have been driving the software development for a long time. A new paradigm is been progressively explored: the service-oriented. This new model is composed by three entities that have the following functionalities: to publish a service (the service provider); to find, to invoke a service (the service requester); to bind, and to store available services (the service registry). This paper introduces the concepts of service-oriented architecture, and presents some innovative testing design and practices for verifying and validating serviceoriented applications. Keywords: Service-oriented, unit test, reflection, service API testing, automatic testing, test patterns. 1. Introduction Software applications are gradually evolving from the object-orientation to service-orientation paradigm, this is clearly noted with the success and adoption of web services in a wide variety of enterprise applications. Today there are a number of application frameworks, such as J2EE, ASP.NET, OSGi, RPG and others, that uses Service-Oriented Architecture (SOA) to provide users' applications a collaborative environment where business parties can export and import services. Even though SOA is been gradually integrated on enterprises applications there are a lack of testing techniques designed for SOA applications in the software engineering literature. On this light, new techniques are necessary to verify and validate applications based on SOA concepts. This paper proposes test cases design and practices to be used as a testing pattern in any automatic testing process that aims to evaluate the behavior of SOA applications. These patterns were designed for Java language; however they are somehow agnostic, and can be implemented using other programming languages. This work focuses on unit tests, services contracts tests, and automatic API testing. The proposed SOA testing techniques were designed during the JSR-232 TCK development at C.E.S.A.R. On this project the JCP group worked together with the Mobile Expert Group (MEG) of the OSGi Alliance to standardize the set of mobile services to run on top of OSGi framework. Motorola (as a member of the OSGi Alliance) actively contributed with MEG specifications, and C.E.S.A.R. was responsible for doing the compliance testing of these new services Scope The concept of service-orientation, which is the foundation of this work, is discussed in the next section. Section 3 presents a unit test approach for SOA applications. Section 4 describes techniques for testing services contracts. Section 5 shows how to make automatic API testing by identifying some patterns in the tested methods. Section 6 presents our conclusion about SOA testing design and practices. References are given at section Service-orientation In a service-oriented environment applications are assembled from reusable building blocks [1] called services. On this environment services are described and organized to support their dynamic, automated discovery and use. In this model services can be used by arbitrary clients, and the service providers are not tied to any particular client, instead, the service providers are interchangeable [2]. In a service-oriented environment there are always three entities: service provider, service requester, and the registry. The services provider publishes a service description and provides the implementation for the service; service requesters finds the service description in the service registry, binds, and invokes the service; the service registry is a directory that contains available services, this entity accepts and stores contracts from services providers and provides these contracts to interested service requesters [3]. The contract is the specification of the way a requester of a service will interact with the service provider. It specifies the format of the request and response from the service. Figure 1, shows the architectural design of SOA applications.

2 Service Provider Bind Service Requester test optional services features or not. Figure 2 indicates that test cases should avoid users interactions in order to keep the integrity of the test results. Contract Publish Discover Test Case Service Registry Figure 1 - Service-oriented design 2.1. Service-oriented test guidelines When developing a component, it is indispensable to test the correctness of the code. Therefore, planning and executing test cases are an excellent way to assure a welldone work. However, it is recommended that the tests be done along with the product being developed. In that way, the errors can be detected as early as possible (even in requirements and design phases), avoiding rework. Testing is not the final hurdle to release the code [4], it must be treated as a continuous activity. There are many thoughts to keep in mind when writing test cases for a SOA application, which is quite different from a user oriented application. The table below shows a comparison of these two kinds of applications testing: Table 1 - User Oriented x Service-Oriented User Oriented Bases tests on requirements Tested API is never changed Business process is usually an entity Assumes components will be always present Service-Oriented Bases tests on services contracts Normally extends services interfaces for testing Business process is a set of services Assumes components have a dynamic availability However there are also some good practices of nonfunctional requirements of software engineering that may be considered and sometimes disregarded [5] when writing test cases for SOA applications. We will focus on robustness, performance, ease of use, and coding Robustness Test case developers must always try to perform automatic testing when possible. It is not a good practice to ask users for inputs or any kind of interaction, it may lead to unexpected test results. Users may provide a wrong input to the test case, and this would be very difficult to identify. A separate test case properties file could be used to overcome this problem, this way test cases could get all the input values, and decide whether to Avoid user interaction Get configuration inputs from files Figure 2 - Configuration design On the other hand the tests may disregard some good practices, such as when the test is executed in an environment where the developer can share static variables with the services under test. Sometimes this is the only way a test case can evaluate the behavior of a service after removal of the service reference. For user applications it is not recommended to share static variables among threads and classes because it is not trivial to keep the synchronization of the variable value. However for testing purposes this approach overcomes the problem of getting key values from the service under test after its removal from the registry. Figure 3 shows the design of a test case that shares static variables with services under test in order to get valuable data for the test results. Static Variable Test Case Performance Share Uses Figure 3 - Static variable sharing Test environment Service under Test Performance is not a primary concern when writing test cases, actually there is no non-functional requirement that is more important than generating a good quality test result. For instance test case developers must do all efforts to cleanup a test case state before the execution of another test. Otherwise the unwanted state left on the application may lead the test suit to produce a wrong test result.

3 For example, in a SOA environment this means if a test case may have to register a service for testing, it must be unregistered after the test case execution; otherwise the service registry will contain unwanted services references Ease of use In a SOA environment there are many events that may occur asynchronously. These events may also have to be validated in some test suits. Therefore test case developers should never care about leaving test executers waiting forever for asynchronous events, yet another definition for do not handle timeout. If the tests are to be executed in an embedded device it is not predictable how much time an event will take to occur. So, it is recommended to leave the responsibility of stopping the execution, due to a timeout failure, to the test framework Coding The test cases must validate the services interfaces, not the services implementations. In other words, the test cases developers should not read the services implementation source code in order to write the test cases. One of the key principles of service-orientation is to hide the implementation details, so the only interface between implementers and test case developers are the services specification. In case of a Java services, the JavaDoc of the services interfaces is the main source for writing the test cases. When writing a test suite for many different services, you need to consider whether these services are optional or not. The mandatory services must always be tested: if they do not exist in the service registry, the test case must fail. On the other hand, optional services may not exist and, even so, the test must not fail. It should be shown in the test result as a warning or something similar. It also impacts integration tests, because in a SOA environment the components have a dynamic availability Unit test pattern When writing unit test a good pattern is to separate each method of the tested API in different classes giving the class the same name of the method under test, and each functional aspect in a different test case. Doing this is better than putting many different tests in only one test case, because it improves the readability of the code, facilitating the understanding of what the test case really does. For each test case you can write a specific documentation, associated with a unique identification number, hence that code can be analyzed by everyone. Even the test results should have this identification, avoiding waste of time when finding which test case failed, debugging or anything similar. 3. Unit tests in a service-oriented architecture A unit test is a code that tests individual units of software or hardware. It is done by executing a method and checking if the result was the expected. In case of SOA it can be an interface or a method [6]. Normally, the developer who has created the code writes the unit test while or even before writing the program itself [7]. There are some exceptions, for example, when testing standardized technologies. In this case, it is necessary to have a testing team just for evaluating the compliance of the standards implementation. For SOA test cases, the validations are based on the behavior of a specified service (contracts and use cases), defined by an interface. Thus, you do not know how it is implemented (black-box approach), all you know is the behavior and features of that service [8]. Therefore you cannot ensure anything about that code, even if it seems obvious. Testing services is a bit different from testing objects because you cannot directly instantiate them, you need to get the instances from the service registry before using them. Consequently the services must be registered before being gotten. What you get is defined by the interface, and its implementation is not visible. Figure 4 - Unit test pattern The Figure 4 - Unit test pattern above illustrates this pattern. There is an interface called IntefaceUnderTest (the service being tested) that has two methods, methoda and methodb. In this case would exist a package called IntefaceUnderTest and two classes (called MethodA and MethodB), each one tests its own method. Supposing that you find out three different tests needed to be done for the first method, they would be inside the respective class MethodA and would be called from testmethoda001 to testmethoda003 following the pattern test[class with the same method name][test index with three digits]. There can be some utility methods to be used commonly by these test methods preventing code replication. All of these test methods should be private to its respective class. The unit tests for a given class should

4 be executed by calling a public void method, called run. To facilitate the readability of the testing code this run method should be called from the TestControl class in a method which follows the pattern: test[interface under test][class with the same method name]. In our example it would be called testinterfaceundertestmethoda and testinterfaceundertestmethodb. 4. Services contracts testing In a service-oriented architecture an interface contract is a published agreement between a service provider and a service consumer, the specification of the way the requester will interact with the publisher. During this find and execute process the requester must fulfill a set of preconditions and post conditions, in order to be in conformity with the contract specification. Suppose a service Publisher has a known interface by the service Requester; however every time the Requester access the Publisher, the latter must invoke the Contract 1, which will do some important actions for the application. Although the execution of Contract 1 is hidden from the Requester its execution must not fail, otherwise the whole invocation of Publisher service will fail. Figure 5 - Services contract design shows an overview of a services contract design. Component A Publisher Contract 1 Component B Requester Contract 2 Figure 5 - Services contract design 4.1. Services contracts test pattern Although the contracts are necessarily hidden from other components, for testing purposes it must be transformed from an internal structure to an external structure. Exposing functionalities is strictly bound to public interfaces, so to test the services contracts we must use a tricky technique that uses interfaces inheritance extending the service contracts to expose key values for later evaluation of the service execution. Considering the contract has a published ServiceInterface with methods that will do something for the component. In order to evaluate the execution of each public method a test case developer could extend the ServiceInterface to a ServiceInterfaceTest, which will have a ServiceInterfaceTestImpl implementation, to make public some handy methods that will expose key values of the service execution. Therefore instead of registering a ServiceInterface implementation in the service registry, the test case developer must now register a ServiceInterfaceTestImpl as the implementation for the ServiceInterface contract. The Figure 6 - Services contracts testing pattern shows a pattern that can be used to verify the services contracts implementations. Figure 6 - Services contracts testing pattern For instance, consider a cash-machine service. The service requires that a client validation request contain the account number, amount, and a special system code [9]. The service uses the system code to determine in which internal database to find the account. There is no reason to expose the system code outside the component that validates the client, because the service should identify the database itself based on the functional data passed into it. This information is only necessary for implementation, but the execution will fail if the system code is wrongly generated by the validation component. The extended testing interface that tests the client validation should have a method that returns the hidden system code. Thus, if test case developers use the proposed pattern, the problem of writing a unit test to validate system code generations in client validations services components of cash-machines, can be overcome. 5. Services API testing with reflection Firstly, it is necessary to understand what reflection is and its advantages before understanding its application in services API testing [10]. Reflection in a programming language context refers to the ability to observe and/or manipulate the inner workings of the environment programmatically [11]. For example, it is possible to discover the methods of a given

5 class and invoke any method as necessary. Note that you do not have to know the methods names, and you can also discover how many parameters each method has. Reflection is a powerful tool that can improve the team productivity, the code legibility and as result, the test suit user get an effectiveness tests result that is definitely the goal of a test suit. There are some myths about reflection that must be clarified before using it [11]. Two cases are described below: Reflection is too complex for use in test applications. This assumption is false. It requires a skill that is easily mastered, and at end, you will have reduced the footprint of your test suit. Reflection reduces applications performance This assumption is also false. It depends of the test design. It can actually increase the performance of the code. It can also simplify the source code design and greatly expand the capabilities of the test suit. Besides performance is not a primary requirement of the test cases. At this point, you know what reflection is, so the concepts and patterns of API testing can now be introduced. As said before, there are many advantages of using reflection in test cases design but be careful when choosing what techniques will be used and what will not be used. When using reflection it is hard to forget to test a method but there is a problem when finding and grouping the methods, reflection API will try to return the first instance of a method found dynamically [12]. Therefore, if the methods are overloaded, it is difficult to find the exact method with the right arguments. The most important thing is to identify which methods could be tested. It is necessary to distinguish which methods have the same behavior and group them by what they have in common, for example group all the methods that throw the same exception in a specific class (See Figure 7 - Grouping methods). Figure 7 - Grouping methods Get all the methods that receive one parameter and throw NullPointerException and use a test method to test their exception. It is important to note that each group of method will be tested in a separated test method. Observe that is not common to test methods that have the same actions but are in different classes, it is recommended to group only the methods that are in a common class, otherwise, it will be difficult to identify which test has failed, if it was on class A or class B for example. The other methods that have a specific behavior may continue being tested normally, without using reflection. It is important to remember to only use reflection when the class or interface has many methods with the same behavior. Figure 8 shows the class design of a test case that uses reflection in order to automatically test the services interfaces methods. Figure 8 - API testing with reflection Additionally, that there are some cases, in which the reflection use will not be so clear, such as when there are only two or three methods which have the same behavior. In these cases you can choose to use reflection or not, it is your choice, it depends on your project. For example, if the class has three methods but in a near future is possible to have others methods added to this class, you may choose to use it. It is not recommended to use many control flow statements (such as switch, if/else) inside a reflection test method, if you are using it, you probably should revise your code verifying if you can test them without using reflection or if you have to split them in two or three distinct groups. 7. Conclusion Even though application testers have decades of experience in software testing, there are many mysteries yet to solve, in order to verify and validate complex software. As complexity grows, researchers find more innovative ways to address the problem of software testing. SOA is the latest trend to be solved; it addresses the problem of applications integration, system availability, reliability, scalability, and modularity. As enterprises gradually integrate SOA solutions into their suit of applications, the complexity of these solutions grows, as well as the quality assurance process.

6 Since testing frameworks and practices driven to SOA environments are missing in the software engineering literature, this paper contributes with new testing techniques to evaluate the behavior of SOA applications, such a contribution are the best practices used during the development of the JSR-232 TCK. A part from that, we found no other work related to SOA testing, which made it difficult to evaluate, and compare our solution with other works. 8. References [1] H. Cervantes and R.S. Hall, Autonomous Adaptation to Dynamic Availability Using a Service-Oriented Component Model, Proceedings of the International Conference on Software Engineering, May 2004; [2] H. Cervantes and R.S. Hall, Automating Service Dependency Management in a Service-Oriented Component Model, Proceedings of the Sixth Component-Based Software Engineering Workshop, pp , May 2003; [3] Ali Arsanjani. Service-oriented modeling and architecture, ibm.com/developerworks/webservices/library/ws-soadesign1/, November 2004; [4] Jon Thomas, Matthew Young, Kyle Brown, Andrew Glover, Java Testing Patterns, Wiley, Indianapolis, Indiana, October 2004; [5] Sean Shubin, Test First Guidelines, XP Magazine, January 2002; [6] Bridge Information Technologies, Software Quality Assurance Processes, QA-PROCESS.pdf, 2003; [7] Per Madsen, "Unit testing using design by contract and equivalence partitions", XP2003, Genova, 2003; [8] Tanja Toroi. "How to Test Software". University of Kuopio, March 2002; [9] James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, Java Web Services Architecture, Chapter 2: Service-Oriented Architecture, Morgan Kaufmann Publishers, May 2003; [10] D. Green, The Java Tutorial: The Reflection API, Sun Microsystems, Inc, ; [11] Michael T. Portwood, Using Java Technology Reflection to improve Design, Java One Conference, San Francisco, 2000; [12] Matthew A. Brown, "Validation Strategy", 9 h Conference on Pattern Language of Programs, Illinois, 2002.