Web services are one of the key building blocks of service-oriented solutions. Because of their usage and importance in the enterprise applications, the project teams are expected to be knowledgeable and familiar with the technologies which are associated with web services and service-oriented architecture(SOA). The testing aspect of web services in particular is one of the key topics which needs to be discussed when you work with web services.
Web servics testing can be performed using many approaches. The client APIs included in web service frameworks such as Apache Axis2 can be used to programatically invoke web services. In addition to that, number of properitory and open source tools are avaialble to test web services automatically. soapUI is one such free and open source testing tool that suppots functional and non-functional evaluations of web services.
We will discuss the following topics in this chapter which will provide you with an introduction to the basic concepts of SOA, web services testing, and soapUI:
Overview of some of the key characteristics of web services
The role of web services in SOA
Approaches of testing web services
Web services testing challenges
Introduction to soapUI
Installing soapUI
SOA is a distinct approach for separating concerns and building business solutions utilizing loosely coupled and reusable components. SOA is no longer a nice-to-have feature for most of the enterprises and it is widely used in organizations to achieve a lot of strategic advantages. By adopting SOA, organizations can enable their business applications to quickly and efficiently respond to business, process, and integration changes which usually occur in any enterprise environment.
If a software system is built by following the principles associated with SOA, it can be considered as a service-oriented solution. Organizations generally tend to build service-oriented solutions in order to leverage flexibility in their businesses, merge or acquire new businesses, and achieve competitive advantages. To understand the use and purpose of SOA and service-oriented solutions, let's have a look at a simplified case study.
Smith and Co. is a large motor insurance policy provider located in North America. The company uses a software system to perform all their operations which are associated with insurance claim processing. The system consists of various modules including the following:
Customer enrollment and registration
Insurance policy processing
Insurance claim processing
Customer management
Accounting
Service providers management
With the enormous success and client satisfaction of the insurance claims processed by the company during the recent past, Smith and Co. has acquired InsurePlus Inc., one of its competing insurance providers, a few months back.
InsurePlus has also provided some of the insurance motor claim policies which are similar to those that Smith and Co. provides to their clients. Therefore, the company management has decided to integrate the insurance claim processing systems used by both companies and deliver one solution to their clients.
Smith and Co. uses a lot of Microsoft(TM) technologies and all of their software applications, including the overall insurance policy management system, are built on .NET framework. On the other hand, InsurePlus uses J2EE heavily, and their insurance processing applications are all based on Java technologies. To worsen the problem of integration, InsurePlus consists of a legacy customer management application component as well, which runs on an AS-400 system.
The IT departments of both companies faced numerous difficulties when they tried to integrate the software applications in Smith and Co. and InsurePlus Inc. They had to write a lot of adapter modules so that both applications would communicate with each other and do the protocol conversions as needed.
In order to overcome these and future integration issues, the IT management of Smith and Co. decided to adopt SOA into their business application development methodology and convert the insurance processing system into a service-oriented solution.
As the first step, a lot of wrapper services (web services which encapsulate the logic of different insurance processing modules) were built, exposing them as web services. Therefore the individual modules were able to communicate with each other with minimum integration concerns. By adopting SOA, their applications used a common language, XML, in message transmission and hence a heterogeneous systems such as the .NET based insurance policy handling system in Smith and Co. was able to communicate with the Java based applications running on InsurePlus Inc.
By implementing a service-oriented solution, the system at Smith and Co. was able to merge with a lot of other legacy systems with minimum integration overhead.
When studying typical service-oriented solutions, we can identify three major building blocks as follows:
Web services
Mediation
Composition
Web services are the individual units of business logic in SOA. Web services communicate with each other and other programs or applications by sending messages. Web services consist of a public interface definition which is a central piece of information that assigns the service an identity and enables its invocation.
The service container is the SOA middleware component where the web service is hosted for the consuming applications to interact with it. It allows developers to build, deploy, and manage web services and it also represents the server-side processor role in web service frameworks. A list of commonly used web service frameworks can be found at http://en.wikipedia.org/wiki/List_of_web_service_frameworks; here you can find some popular web service middleware such as Windows Communication Foundation (WCF), Apache CXF, Apache Axis2, and so on. We will use Apache Axis2 as the service container for sample projects within the context of this book. Apache Axis2 can be found at http://axis.apache.org/.
The service container contains the business logic, which interacts with the service consumer via a service interface. This is shown in the following diagram:
Usually, the message transmission between nodes in a service-oriented solution does not just occur via the typical point-to-point channels. Instead, once a message is received, it can be flowed through multiple intermediaries and subjected to various transformation and conversions as necessary. This behavior is commonly referred to as message mediation and is another important building block in service-oriented solutions. Similar to how the service container is used as the hosting platform for web services, a broker is the corresponding SOA middleware component for message mediation. Usually, enterprise service bus (ESB) acts as a broker in service-oriented solutions.
In service-oriented solutions, we cannot expect individual web services running alone to provide the desired business functionality. Instead, multiple web services work together and participate in various service compositions. Usually, the web services are pulled together dynamically at the runtime based on the rules specified in business process definitions. The management or coordination of these business processes are governed by the process coordinator, which is the SOA middleware component associated with web service compositions.
We looked into the primary building blocks of service-oriented solutions and the corresponding SOA middleware components. Next, we are going to discuss some of the distinguished elements associated specifically with web services. These are SOAP messaging, Web Services Description Language (WSDL), message exchanging patterns, and RESTful services.
Simple Object Access Protocol (SOAP) can be considered as the foremost messaging standard for use with web services. It is defined by the World Wide Web Consortium (W3C) at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ as follows:
SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.
The SOAP specification has been universally accepted as the standard transport protocol for messages processed by web services. There are two different versions of SOAP specification and both of them are widely used in service-oriented solutions. These two versions are SOAP v1.1 and SOAP v1.2.
Regardless of the SOAP specification version, the message format of a SOAP message still remains intact. A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body.
The structure of a SOAP message is shown in the following diagram:
The SOAP Envelope is the wrapper element which holds all child nodes inside a SOAP message.
The SOAP Header element is an optional block where the meta information is stored. Using the headers, SOAP messages are capable of containing different types of supplemental information related to the delivery and processing of messages. This indirectly provides the statelessness for web services as by maintaining SOAP headers, services do not necessarily need to store message-specific logic. Typically, SOAP headers can include the following:
Message processing instructions
Security policy metadata
Addressing information
Message correlation data
Reliable messaging metadata
The SOAP body is the element where the actual message contents are hosted. These contents of the body are usually referred to as the message payload.
Let's have a look at a sample SOAP message and relate the preceding concepts through the following diagram:
In this example SOAP message, we can clearly identify the three elements; envelope, body, and header. The header element includes a set of child elements such as <wsa:To>, <wsa:ReplyTo>, <wsa:Address>, <wsa:MessageID>, and <wsa:Action>. These header blocks are part of the WS-Addressing specification. Similarly, any header element associated with WS-* specifications can be included inside the SOAP header element.
The <s:Body> element carries the actual message payload. In this example, it is the <p:echoString> element with a one child element.
Tip
When working with SOAP messages, identification of the version of SOAP message is one of the important requirements. At first glance, you can determine the version of the specification used in the SOAP message through the namespace identifier of the <Envelope> element. If the message conforms to SOAP 1.1 specification, it would be http://schemas.xmlsoap.org/soap/envelope/,otherwise http://www.w3.org/2003/05/soap-envelope is the name space identifier of SOAP 1.2 messages.
Though SOAP is considered as the standard protocol for web services communication, it is not the only possible transport protocol which is used. SOAP was designed to be extensible so that the other standards could be integrated into it. The WS-* extensions such as WS-Security, WS-Addressing, and WS-ReliableMessaging are associated with SOAP messaging due to this extensible nature. In addition to the platform and language agnosticism, SOAP messages can be transmitted over various transports such as HTTP, HTTPS, JMS, and SMTP among others. However, there are a few drawbacks associated with SOAP messaging. The performance degradations due to heavy XML processing and the complexities associated with the usage of various WS-* specifications are two of the most common disadvantages of the SOAP messaging model. Because of these concerns, we can identify some alternative approaches to SOAP.
Due to the complexities accompanied with the SOAP model, Representational State Transfer (REST) architecture has emerged as a result. RESTful web services can be considered as a lightweight alternative to the bulky and complex SOAP based web service standards. In RESTful web services, the emphasis is on point-to-point communication over HTTP, primarily using plain old XML (POX) messages. We will discuss RESTful web services in detail in Chapter 8, Getting started with REST Testing.
Java Script Object Notation (JSON) is a lightweight data exchange format similar to XML. It is based on a subset of JavaScript language. JSON uses key value pairs to represent data which are carried inside the message. The following example shows how the XML payload of a SOAP message can be represented in JSON:
The corresponding JSON format of the preceding XML payload is represented by:
You may refer to http://www.json.org for more details about JSON.
According to the WSDL 1.1 specification, WSDL is defined as:
WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services)
In simple terms, WSDL provides a formal definition of the web service through abstract and concrete definitions of the interface. The following diagram shows the main structure of a WSDL document:
WSDL is an XML document with a <definitions> element at the root and the child elements, <types>, <message>, <portType>, and <binding>. These can be explained as follows:
The
<types>element is used to define the data types used by the web service usually through a XML schema. The schema can be defined inline as a child element of<types>or can be imported from an external URL.The
<message>element defines an abstract representation of all the messages used by the web service. A message consists of logical parts, each of which is associated with a definition within some type in the XML schema of the web service. The following image is an example of a message:
The
<portType>element is an abstract representation of the operations and message exchange patterns used in the web service. Operations represent a specific action performed by a web service and which can be related to the public methods used by a program. Operations have input and output parameters and those are represented as messages. Hence, an operation consists of sets of input and output messages. This is evident from the following image:
In the preceding example, the
SampleServicePortTypeelement includes a single child element,<wsdl:operation name="echoString">, which itself includes two child elements to define the input and output messages processed by theechoStringoperation.The
<binding>element connects the abstract web service interface defined by<portType>and<message>elements into a physical transport protocol. A binding represents a particular transport technology that the service uses to communicate. For example, SOAP v1.1 is one such commonly used binding.
We will discuss about the WSDL in detail in Chapter 2, The Sample Project, using the one that is used in the sample project.
As we have already discussed, the web services communicate with each other and the other programs by sending messages. If we consider two SOAP processing nodes, the communication pattern between the two entities can be defined as a message exchanging pattern (MEP). The primary message exchanging patterns are:
In a request-response pattern, when a source entity (service requester) transmits a message to a destination (service provider), the provider should respond to the requester. This is the most commonly used message exchanging pattern and we will use this in most of the examples in this book.
In the following diagram, a service requester sends a SOAP request message to a service provider:
Upon receiving the SOAP request message, the service provider responds with a SOAP response as shown in the following diagram:
When a response to a request message is not expected from a web service (or service provider), it is known as a fire and forget message exchange pattern. For example, if we send a ping request to a web service, we do not expect a response message back.
Before concluding our discussion on web services and the associated concepts, we should look at the fault handling mechanism of web services. Faults can be returned by web services due to various reasons. For example, if the request message does not conform to the XML schema of web service, the service responds back with a SOAP Fault. The SOAP Fault element is used to carry such faults occurred during web service communication. This element must be included inside body of a SOAP message. A typical SOAP 1.1 Fault message consists of the following child elements:
faultcode: Thefaultcodeelement is used to define the type of the fault. For example, if the problem of message transmission is due to the server, the associated faultcode isServer. Similarly, we can useVersionMismatch,MustUnderstandandClienterror codes as appropriate.faultstring: Thefaultstringelement is intended to provide a human readable explanation about the fault.faultactor: Thefaultactorelement provides an indication about the responsible party who caused the fault to occur in the message path.detail: Thedetailelement is used to carry application specific error information related to the body element. For example, if the payload of the SOAP request is unable cannot be processed by web service, the associated response should include the detail element inside the SOAP Fault.
In the case of SOAP v1.2 messaging, faultcode is renamed to Code and faultstring is renamed to Reason. In addition to that, a SOAP v1.2 Fault message can include the optional child elements, Node, Role, and Detail. A detailed explanation of SOAP 1.1 Faults can be found at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507. SOAP 1.2 Faults are explained in detail at http://www.w3.org/TR/soap12-part1/#soapfault.
We discussed a set of concepts most associated with web services. Now, it is time to look in to the testing aspects of web services. As we noticed, web services are loosely coupled and autonomous components which are individual units of business logic in SOA. This facilitates a distinguished approach for testing web services. Because of the loosely coupled nature, the services do not maintain tight, cross-service dependencies with each other. Therefore, once a particular web service is implemented, it can be tested independent from others.
This gives the ability to testers to follow a component level testing methodology. Before moving into various integrations, a web service can be tested to verify both functional and non-functional requirements. Once the service is enhanced with different attributes such as security policies, then such a service can also be tested individually to ensure that it functions properly before taking the integration scenarios into account. This gives great flexibility for testers and provides agility to testing processes.
We can identify a set of common approaches for testing web services as follows:
Unit testing
Functional testing of web services
Integration testing of web services
Performance testing
Let's discuss each of these approaches in detail.
A web service is a unit of business logic and it consists of one or more operations. These operations must be tested individually in order to make sure the intended business problems are addressed by web service operations. Therefore, similar to how individual methods in a computer program are tested as units, web service operations must also be unit tested. Unit tests can be developed using the unit test framework associated with the programming language which is used to implement the web services. For example, if web services are written in Java, JUnit framework can be used as the unit testing framework. Generally, it is the responsibility of the author of the web service to write a sufficient number of unit tests to cover the logic of the web service operations.
Once a web service is deployed in a service container, it is subjected to a comprehensive functional verification. The purpose of functional testing of a web service is to ensure that the expected business functionality is given by the web service. There are many approaches to perform functional testing as explained below.
The primary objective of using tools for web service testing is to support the automatic generation and submission of web service requests. As the web service interface is a machine readable XML document, it is not an easy task to read the WSDL and derive tests manually. Therefore, tools can be used to point to the WSDL and generate the corresponding requests automatically, so that the testers can send them to the service with or without alterations. soapUI is a good example of such a testing tool, which can be used in functional testing of web services.
The life for a web service is given by the service container middleware where the service is hosted. Usually, the middleware providers ship the associated client API libraries which can be used to invoke web services programmatically without using any third party tool.
Web services do not essentially run alone. Instead they are integrated with multiple components such as brokers or service coordinators. Once a service is integrated or joined with another component, we should carry out tests to make sure that such integrations do not break the system. For example, in a service-oriented solution, if a service consumer application sends a message to a web service but the message does not conform to the advertised schema of the web service. In this case, the web service usually responds with a SOAP fault. However, if we want to take such a request and transform the request SOAP message such that it is valid according to the schema, then we do not want to ask the consumers of our web service to change the client applications as the service schema is modified. This type of message transformation is achieved by using a broker component, in other words, enterprise service bus (ESB) middleware. According to the transformation rules defined in the enterprise service bus, the request is converted into the correct format and forwarded to the web service. This is a typical example of web service integration. In order to test this type of integration, the request message should be forwarded to the ESB component instead of directly sending it to the web service. Tools such as soapUI can easily be used to send the messages to desired target locations appropriately.
Once we are satisfied with the functional aspects of the web service, it should be tested thoroughly for performance. This includes load and stress testing the web service as well as measuring the performance under various conditions. We can use various open source or commercial tools in web services performance testing. Apache JMeter (found at http://jmeter.apache.org/) is a good example of an open source testing tool which can be used to test web services. The functional tests which we create on soapUI can easily be extended to test the performance of web services. We will discuss the performance testing capabilities of soapUI in detail in Chapter 5, Load and Performance Testing with soapUI.
When compared to traditional testing approaches, there are some unique challenges associated with web services testing.
The autonomous and loosely coupled nature of web services introduces a greater level of scalability and extensibility to the system. All services included in a system are not necessarily built in-house. Some web services can be developed and hosted by third parties. These services can be dynamically discovered and used according to the business requirements. Though this accelerates the delivery of solutions, testing such a system becomes complex because the quality assurance and availability of the third party services are out of your control.
Web services, especially SOAP-based services can use various WS-* specifications. When testing web services which adhere to specifications such as WS-Security, the tester should possess a fair amount of knowledge about the standards and concepts to carry out testing effectively. This introduces a higher learning curve for testers to get started with the testing of web services.
Web services can also be exposed over multiple transport protocols. Thus, testing is not limited to one particular transport such as HTTP. The same web service can be made accessible over transports such as JMS or VFS which requires changes in the testing setup as well as a different set of test scenarios.
In traditional web application testing, test scenarios can be identified quite easily by studying the GUI of the components. As we discussed previously, the operations of web services are exposed to the outside world via machine-readable service contracts (such as WSDLs). Thus, during the early stages of web services development, testers need to use WSDLs as the reference for the derivation of test scenarios which can be difficult as compared to exploring a GUI.
As we proceed with the chapters of this book, we will learn how soapUI addresses some of the aforementioned challenges and make the life of a web services tester easier.
We have discussed the fundamentals of SOA and web services testing. Now, we are ready to explore the world of web services testing with soapUI.
The primary objective of designing testing tools is to assist people in testing software by reducing the time taken by test execution. There are different types of tools which can be used for functional and non-functional testing. Some of the tools are designed to automate user interface based interactions and some are used to derive various types of requests messages automatically and transmit them to applications with or without modifications. Some tools support both of these aspects.
soapUI is a tool which can be used for both functional and non-functional testing. It is not limited to web services, though it is the de-facto tool used in web services testing. In web services testing, soapUI is capable of performing the role of both client and service. It enables users to create functional and non-functional tests quickly and in an efficient manner by using a single environment.
The first release of soapUI (v1.0) was in October 2005. Ole Lensmer, while working in a project related to SOA, felt the need for a testing tool to support agile development. Therefore, he started to develop soapUI in his spare time. Eventually, the project was open sourced and the community grew. Ever since, a number of versions have been released with various new features and enhancements and the newest version of soapUI is 4.0.1 at the time of writing this book.
The originator of soapUI, Ole Lensmer was managing the project releases through a company called Eviware for the past few years. In July 2011, Eviware was acquired by SmartBear Software (http://smartbear.com/) and now soapUI is part of SmartBear Software.
soapUI is a free and open source utility, which means you can utilize the various features provided by the tool freely as well as you are allowed to make modifications to the source code of soapUI and suit it according to your requirements. soapUI is licensed under the terms of the GNU Lesser General Public License (LGPL). It has been implemented purely using Java platform hence it runs on most operating systems out of the box.
It should be noted that soapUI is also distributed as a non-free commercial version known as soapUI Pro, which basically provides users with custom utilities and enhanced production level testing capabilities. All our discussions and examples are based on the free version of soapUI for your convenience.
The primary goal of the authors of soapUI is to provide users with a simple and user-friendly utility which can be used to create and run functional as well as non-functional tests through a single test environment. Based on that objective, soapUI has become the world's leading SOA and web service testing tool. soapUI can be installed with no configuration overhead in most of the common operating systems which allow users to start using the tool without spending time on configuring various installation prerequisites.
By using the easy-to-use Java Swing-based GUI, you can start creating functional tests with zero coding. Eventually, the same functional tests can be used for load and performance testing through the same test environment. This gives users a great flexibility since all functional and non-functional tests can be managed through a single point of access.
Let's look at some of the important features of soapUI which we are planning to discuss in the following chapters.
Complete coverage of functional aspects of web services and web applications: soapUI supports most of the standards used in web applications, such as message transmission through HTTP, HTTPS transport as well as JMS. It also supports testing SOAP and RESTful web services. Specifically, soapUI supports most of the web service specifications such as WS-Security, WS-Addressing, among others.
Service mocking: Using soapUI mock services, you can simulate the web services before they are actually implemented. This gives you the ability to test the web service consumer applications without waiting until the web service providers are implemented.
Scripting: Either using Groovy or JavaScript, soapUI allows you to do various pre- or post-processing test configurations such as dynamic mock responses, initialize or cleanup tests, dynamic mock operation dispatching, and so on.
Functional testing : soapUI lets you do functional verifications against web services, web applications, and JDBC data sources. You can validate responses of your tests using various in-built and custom assertions. It also allows you to add conditional test steps to control the test execution flow.
Performance testing: With just a few clicks, you can generate performance and load tests quickly using soapUI.
Test automation: soapUI can be integrated into automated test frameworks such as JUnit, and the tests can also be launched through Apache Maven and Apache Ant build frameworks. It can also be integrated into continuous integration tools such as Hudson or Bamboo.
In addition to the preceding features, the proprietary version of soapUI, soapUI Pro, provides users with data-driven testing capabilities, HTTP recording, and test reporting facilities which are not in scope of this book.
We looked at the major features provided by soapUI and discussed the tool in general. It is time to explore the easy and straightforward soapUI installation on some of the popular operating systems.
To be able to run soapUI, you should have Java Development Kit (JDK) v1.6 running in your system. As soapUI is implemented in Java, it runs on many operating systems including Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, various Linux flavors such as Ubuntu, Red Hat, Fedora, SuSE, and CentOS, and Mac OS X v10.4 or higher.
We can summarize the system requirements to install and run soapUI as follows:
Let's discuss the installation procedure of soapUI in each of the preceding operating systems in detail.
soapUI is distributed as two different installers for your convenience. You could either download the binary archive (ZIP) of the installer or the installer script.
First, we will look at the installation procedure of the binary archive. Perform the following steps:
Download the Linux binary zip version (for example
soapui-4.0.1-linux-bin.zip) of the latest soapUI release from http://www.soapui.org.Extract the downloaded binary distribution into a directory in your local file system, for example
/home/user/soapui.Go to
SOAPUI_HOME/binand run thesoapui.shstartup script as follows:./soapui.sh. This will launch the soapUI graphical user interface.
Tip
If you encounter a Permission denied error when running the soapui.sh script, make sure to change the file permission mode by granting executable privileges to the user by executing the chmod command as chmod 755 soapui.sh.
You can also install soapUI using the Linux installer by performing the following steps:
Download a soapUI Linux installer (for example
soapUI-x32-4_0_1.sh) from http://www.soapui.org.After the file is downloaded, give executable permissions by running the command,
chmod 755 soapUI-x32-4_0_1.sh.Run the installer as follows:
./soapUI-x32-4_0_1.sh.This will launch the installer UI as shown in the following screenshot:
Now, you can proceed through the installation wizard. You will be asked to accept the license agreement at the next step of the wizard. Simply click on I accept the agreement option and click on Next. You will be required to specify a destination directory for soapUI to be installed.
At the next step of the installation wizard, you can select which components you need to include in soapUI, such as; Hermes
JMS, soapUI source files, and tutorials. Simply accept all options and click on Next. You will be prompted with the license agreement for Hermes components at the next step. Accept the license agreement and click on Next to proceed through the wizard. Then, you will be asked to specify a directory for soapUI tutorials. Enter a location which is in your filesystem and click on Next. You will be asked for a directory where soapUI symlinks are created for executables such as the soapui.sh file. Enter a directory and click on Next. You can check the Create a desktop icon checkbox to create an icon on the desktop so can you can easily launch soapUI. Finally, click on the Next button to start the installation.
The soapUI installation screen will look like the following screenshot:
Similar to the preceding installation procedure on Linux, soapUI can be installed on a Windows operating system either using Windows installer or Windows binary archive.
Let's look at the installation steps of Windows binary archive. They are as follows:
Download the Windows binary zip version (for example
soapui-4.0.1-windows-bin.zip) of the latest soapUI release from http://www.soapui.org.Extract the downloaded binary distribution into a directory in your local filesystem, for example
C:/soapui.Go to
SOAPUI_HOME/binand run thesoapui.batstartup script by executing the command:soapui.bat.
The steps for soapUI installation using the
Windows installer are almost the same as the steps given in the Linux installer. You just need to double-click on the installer (soapUI-x32-4_0_1.exe) and it will launch the soapUI installation wizard.
soapUI is a self-explanatory testing tool. The easy-to-use user interface makes it simple to work with soapUI for any type of user. With a few clicks, you can start testing a web service or a web application with minimum effort. This highly usable and flexible user interface helped soapUI to become the most user-friendly and easier SOA and web service testing tool among the testing community.
Once soapUI is launched, you will be shown the starter user interface as shown in the following screenshot:
In soapUI, all tests are organized under a central element, known as Projects. Just by right-clicking on the Projects node in the left-hand side pane in soapUI GUI, a new soapUI project can be created as shown in the following screenshot:
I will leave it to you to navigate through the rest of the UI elements on your own before starting with sample projects. You will find a lot of materials on the soapUI official website related to these features. We will explore through the soapUI user interface as we proceed through the demonstrations and samples in the rest of the chapters.
Web services are the individual units of business logic in SOA. In order to test web services, we must possess a good understanding about SOA and web services as well as the associated technological components. This chapter has been dedicated to build that foundation.
We started to look into soapUI, the world's leading and most complete SOA and web services testing tool. We discussed the primary goals and objectives of using soapUI in web services testing. We looked at a bit of history of soapUI and its distribution models. Finally, the steps of installing soapUI on Linux, Windows, and Mac OS were explained.
Now, we have soapUI running on our systems. Let's get our hands dirty with a sample project in the next chapter.
