15th meetup thessaloniki_softwaretestingqa_vasilispetrou_testingwebserviceinobjectorientedway

Vasilis PETROU | Test Automation Lead
Testing Web Services
with an Object-Oriented way
15th Thessaloniki Software Testing and QA Meetup

Vasilis Petrou
“Knowledge is only real when shared”
֍test automation lead at INTRASOFT International;
֍more than 11 years experience in full-stack
development and more than 4 years in test
automation;
֍co-organizer of Software Testing & QA Meetup
Thessaloniki Greece;
֍volunteer organizer of lectures about Software
Testing & Test Automation in Universities &
Institutions.
15th Thessaloniki Software Testing and QA MeetupVasilis PETROU | Test Automation Lead | INTRASOFT International

Thessaloniki Software Testing & QA Meetup
Google Docs For Proposals
https://tinyurl.com/y6nm4l9w

Thessaloniki Software Testing & QA Meetup
Slack Channel
https://tinyurl.com/y4gw24p2

headcount
2.000+ professionals
20+ nationalities
500+ organizations worldwide
have chosen our services
eu institutions
public sector
enterprise solutions
47% university graduates
24% msc/phd holders
key player in
e.u. institutions and
agencies for 20+ years
established in 1996 in
luxembourg, operations
in 13 countries
outstanding record
in over 70+ countries
around the globe
a leading european IT solutions
& services company
more than 25% growth
in revenue over
the past 2 years
#WeAreIntrasoft

 independent Testing Team of
INTRASOFT International
 one of the biggest Testing
Centers in Greece
 more than 20 test engineers
do automation
 large number of
implementations on the
testing types included in the
tree
Functional Performance
GUI
Data
Migration
Non-
Functional
API
Usability
Configuration
StressLoad

Azure
Devops

to test web services
we will use

why SoapUI?
 user-friendly GUI
 easy for functional testing
 automation with Apache Groovy
 data-driven testing
 assertions
 it’s free!!!
SoapUI Open Source is a free for Commercial Use
Software under the terms of European Union
Public License (EUPL V.1.1).

what are web services?
web service is a software system designed to support
machine-to-machine interaction over a network.
- W3C -

what are the types of web services?
SOAP & REST Web Services

what are the SOAP Web Services?
Simple Object Access Protocol (SOAP) is an XML-based protocol.
the biggest advantage of using the SOAP Web Service is its own security.
SOAP provides an envelope to send a web services messages over the Internet, using the HTTP protocol.

what are the REST Web Services?
Representational State Transfer (REST) is a style of software architecture
for creating web services using predefined operations GET POST PUT DELETE.

let’s start practice
to automate web service tests

but first, what do we need?
of course, a web service

prepare to build a Web Service Application
step 1
assuming that we work on a Windows OS machine, next steps
should be followed to build an indicative Web Service Application

download and Install
JAVA 8
https://www.oracle.com/technet
work/java/javase/downloads/jdk8
-downloads-2133151.html
step 1. prepare to build a Web Service Application (1 of 5)
* don’t forget to set JAVA_HOME environment variable

Maven
http://maven.apache.org/downlo
ad.cgi
* don’t forget to set MAVEN_HOME environment variable

Docker for Windows
https://docs.docker.com/docker-for-
windows/install/
* don’t forget to update settings and share your drive.

GIT for Windows
https://gitforwindows.org/

download
an indicative Web
Service Application
from my GIT Repo
https://github.com/vpetrou/spring-boot-
soap-ws
* the Web Service Application is written in JAVA Spring Boot with MySQL DB

build the indicative Web Service Application
step 2

right click on the
folder with the
indicative Web
Service Application
and select
GIT Bash here
step 2. build the indicative Web Service Application (1 of 3)

from the Git Bash
window, execute the
command:
./install.sh
and wait until the
application is started. * ports 8080 and 3306 are used by the Docker Containers

visit URL:
http://localhost:8080/soapws/contacts.wsdl
to verify that Web Service is
Up & Running.
the Web Services Description Language
(WSDL) is an XML-based interface
description language that is used for
describing the functionality offered by a web
service.

analyze the Web Service under Test
step 3

the name of the web service is ContactsPortService
step 3. analyze the Web Service under Test (1 of 5)
this service contains CRUD service operations
* definition of CRUD: Create Read Update Delete

available Service Operations of ContactsPortService:
 addContact: to add a new contact;
 updateContact: to update a contact;
 deleteContact: to delete a contact;
 getAllContacts: to get a list of all contacts;
 getContactById: to get a contact by Id;
 getContactByName: to get all contacts that contain all or part of given name.

columns of table Contact:
 contactId: numeric(1..5), Key, Auto Increment;
 name: Not Null, Alphanumeric(1..30);
 nickName: Alphanumeric(8), Pattern (4 letters and 4 numbers)
 category: Alphanumeric(0..30)
 phone: Numeric(0..14)
 email: Alphanumeric(0..30), Email Pattern (…@...)
 city: Alphanumeric(0..30)
 country: Alphanumeric(0..30)

proof of concept (PoC):
We will create some indicative test cases for the “addContact” service operation.
Each Test Case will contain a groovy step to generate a random “nickName” with
the accepted pattern “4 letters and 4 numbers”.
After the implementation, a request for change will be handled to check the
maintenance effort. This request for change will be related with the column
“nickName” where the pattern changes to “4 letters and 6 numbers”.
The maintenance effort between the 2 different implementation methodologies in
SoapUI will be compared.

indicative Test Cases for the test suite TS-SRV-AddContacts :
 TC-SRV-AddContacts-P-001: Tests the addition of a contact where all the fields are inserted
with valid value.
 TC-SRV-AddContacts-N-001: Tests the addition of a contact where all the fields are inserted
with valid value except field ‘email’ which has invalid value.
with valid value except field ‘phone’ which has invalid value.
with valid value except field ‘nickName’ which has invalid value.
* naming convention of Test Case ID: TC = Test Case, SRV = Services, AddContacts = Service Operation, P = Positive or N = Negative, 001 = Serial Number

prepare to build Web Service Test Scripts
step 4

SoapUI Open Source
https://www.soapui.org/downloads/soa
pui.html
step 4. prepare to build Web Service Test Scripts

build Web Service Test Scripts via SoapUI
with the common way
step 5

open SoapUI Open Source
step 5. build Web Service Test Scripts via SoapUI with the common way (1 of 16)
and start a new project (e.g. SEETest-SrvTests) selecting “New SOAP Project”

before proceeding with test cases, select “Save Project”
* it is not mandatory to save the project at the beginning. It is
just a suggestion in order not to forget to save it before exiting.

right click on SoapUI Project and
select option “New TestSuite”
then specify the name “TS-SRV-
AddContacts” for the new test
suite.

right click on Test Suite “TS-SRV-
AddContacts” and select option
“New TestCase”
then specify the name “TC-SRV-
AddContacts-P-001” for the new
test case.

right click on Test Case “TC-SRV-
AddContacts-P-001” and select
option “Add Step” and “Soap
Request”
then specify the name
“AddContactWithAllFieldsValid”
for the new step.

specify additional options for the
new step (e.g. “Add SOAP Response
Assertion” to be checked).
specify the service operation
“addContact” to invoke for the request.

right click on Test Case “TC-SRV-
AddContacts-P-001” and select
option “Add Step” and “Groovy
Script”
then specify the name
“GenerateNickName” for the
new step.
create a groovy step to generate a nickname

drag ‘n drop step
‘GenerateNickName’ to be first
in the list of steps of test case
“TC-SRV-AddContacts-P-001”

step ‘GenerateNickName’ returns a random string with 4
letters and 4 numbers:
* this groovy step is indicative, just for demonstration reasons.

now, we will insert values in all fields of step
‘AddContactWithAllFieldsValid’:
* ${GenerateNickName#result} returns the result of groovy step GenerateNickName

running step ‘AddContactWithAllFieldsValid’ we will see a
response with SUCCESS status code:

add an assertion to step ‘AddContactWithAllFieldsValid’ to
verify that response contains the word “SUCCESS”:

finally to be able to run and re-run the same test case insert the appropriate
steps to get the new generated contact ID and remove the contact.

after we get the new generated contact ID via a Groovy step, we can
use it in a next Soap Request step to remove the Contact.

repeat above steps (or clone) to implement the rest test cases.
* test case TC-SRV-AddContacts-N-003 will be the only one that will not contain groovy step “GenerateNickName”.
A full run proves that tests work properly.

build Web Service Test Scripts via SoapUI
with the object oriented way
step 6

open SoapUI Open Source
step 6. build Web Service Test Scripts via SoapUI with the object oriented way (1 of 8)
and start a new project (e.g. SEETest-SrvTestsV2) selecting “New SOAP Project”

to avoid the re-creation of test cases just right click and select “Clone
TestSuite” to clone test suite of SEETest-SrvTests to SEETest-SrvTestsV2
before proceeding with test cases,
select “Save Project”

step “GenerateNickName” of test cases
• TC-SRV-AddContacts-P-001
• TC-SRV-AddContacts-N-001
• TC-SRV-AddContacts-N-002
will be updated with the use of
External Groovy Script

why to use External Groovy Script?
implementation of repeated steps will be handled from a single point.
so, if an update affects these steps, the effort to update them is almost
nothing in relation to the effort it takes to update all the affected steps
one by one.

in the same folder with the SoapUI project (SEETest-SrvTestsV2-
soapui-project.xml) create a file with name “seetest.groovy”
copy-paste the content of Groovy Step “GenerateNickName”
to External Groovy Script “seetest.groovy”

method “getNickname()”
returns an auto-generated
nickname based on
pattern (4 letters + 4
numbers)

in SoapUI Project update groovy Step “GenerateNickName” (for all test
cases) to call method “getNickname()” from the External Groovy Script
“seetest.groovy”
* above implementation is based on GroovyScriptEngine: http://docs.groovy-lang.org/latest/html/api/groovy/util/GroovyScriptEngine.html

the implementation of method “getNickname()” is now out of SoapUI
which means that any change about how the nickname should be, will
affect only External Groovy Script “seetest.groovy”.
a full run proves that tests work properly.

update Web Service Test Scripts
based on Request for Change (RfC)
step 7

so, in a next release of the application, our customer decided to
request a change regarding the nickname.
the pattern must change
from “4 letters and 4 numbers”
to “4 letters and 6 numbers”.
step 7. update Web Service Test Scripts based on Request for Change (RfC)(1 of 4)

based on the 2 different implementation methodologies in SoapUI
(step 5 & step 6), below is displayed a table of affections:
Common Methodology Object Oriented Methodology
Affected Test Steps in SoapUI 3 0
Affected External Groovy Scripts 0 1

based on common methodology each “GenerateNickName”
must be updated in SoapUI.
in this demo project effort seems to be low, but when we are talking about hundreds of
affected test cases and when the update is not such simple allowing us to make a simple
Search-Replace in the SoapUI Project XML file, then maintenance is a real bottleneck.

based on object oriented methodology nothing should be
updated in SoapUI. Only method “getNickname()” of the external
groovy script “seetest.groovy” must be updated properly.
the fact that the effort relates to only one point outside SoapUI makes not only maintenance
easier in terms of the needed actions but also in terms of guidelines. When we deliver a
SoapUI project and something goes wrong it is easier to suggest workarounds by simply
editing content of groovy files than giving workarounds with actions inside SoapUI steps.

in conclusion (1 of 3)
there is a minor disadvantage of using External Groovy Scripts:
 when a part of external groovy method has failure, we must work with 2 different environments.
Meaning that the script can be opened e.g. with Notepad++ (it cannot be opened via SoapUI directly to
quickly edit the script and proceed.
tip: we usually work with external groovy files via IntelliJ Community Edition having installed the Groovy SDK. http://groovy-lang.org/download.html
there we can run and debug groovy scripts and find easier all the needed “imports”.

the advantage of the easier maintenance and the external handling is such significant
that makes the selection of this methodology a real need.
and after this easier maintenance, we feel like…
MVPs

of course, there are applications, where the number of test cases is not large, or the
resources (test engineers) have not the necessary skills.
there is no right or wrong
based on the project’s needs…
the decision is yours to make

where to find the SoapUI Projects?
 GitHub:
https://github.com/vpetrou/srv-tests-soapui

where to find me?
 my GitHub:
https://github.com/vpetrou
 my LinkedIn Profile:
https://www.linkedin.com/in/vasilis-petrou-09a785a3/
 my Emails:
vasilios.petrou@intrasoft-intl.com
petrou82@gmail.com
vasilis.petrou@outlook.com.gr

thank you
questions?

15th meetup thessaloniki_softwaretestingqa_vasilispetrou_testingwebserviceinobjectorientedway

More Related Content

What's hot (12)

Similar to 15th meetup thessaloniki_softwaretestingqa_vasilispetrou_testingwebserviceinobjectorientedway (20)

Recently uploaded (20)

15th meetup thessaloniki_softwaretestingqa_vasilispetrou_testingwebserviceinobjectorientedway