Xiaoming Ma

Development and Automation of a

Web Applications Using FastAPI,
Jenkins, and Robot Framework

Metropolia University of Applied Sciences

Bachelor of Engineering
Information Technology
Bachelor’s Thesis
6 May 2024
Abstract

Author: Xiaoming Ma
Title: Development and Automation of Web Applications Using
FastAPI, Jenkins, and Robot Framework
Number of Pages: 37 pages
Date: 6 May 2024

Degree: Bachelor of Engineering

Degree Programme: Information Technology
Professional Major: Mobile Solutions
Supervisors: Toni Spännäri

Nowadays, it has become increasingly common to utilize numerous different

technologies together to develop a high-performance and reliable web application.
Therefore, choosing and applying the most appropriate combination of technologies
becomes particularly important. This thesis aims to explore the possibilities and
collective benefits of creating web applications using FastAPI, Robot Framework, and
Jenkins pipeline.

The theoretical background chapters establish the foundation for understanding

these technologies, covering concepts, advantages, and methodologies. The case
study chapter offers a thorough examination of objectives, challenges, and
implementation details of a successfully executed restaurant web applications
project, providing practical perspectives into developing web applications with
FastAPI and conducting automated testing with the Robot Framework, in the end
executing Robot Framework test cases and deploying web applications on Linux
CentOS server through Jenkins pipelines.

The author hopes that this thesis will provide an alternative approach and insights for
web application developers who may not be familiar with these technologies.

Keywords: FastAPI, Jenkins, Robot Framework, Backend, CI/CD Pipeline, Test

Automation
___________________________________________________________
Contents

List of Abbreviations

1 Introduction 1

2 Web Applications development with FastAPI 2

2.1 Concept of FastAPI 2

2.2 Advantages and features 2

2.3 Structure of FastAPI applications 5

3 Continuous Integration and Deployment with Jenkins pipeline 6

3.1 Concept of Jenkins and Jenkins Pipelines 7

3.2 Jenkins pipeline development and execution 8

4 Automated Testing with Robot Framework 10

4.1 Concept of Robot Framework 10

4.2 Creating and executing Robot Framework test cases 12

5 Case study 13

5.1 Case study summary 13

5.2 Development of web applications with FastAPI backend 15

5.3 Setting up Robot Framework and creating test cases 22

5.4 Building the Jenkins pipeline for automated testing and deployment 26

5.5 Future implementation 35

6 Conclusion 36

References 37
List of Abbreviations

CI/CD: Continuous Integration and Continuous Deployment

CLI: Command-Line Interface

GUI: Graphical User Interface

DSL: Domain Specific Language

API: Applications Programming Interface

ASGI: Asynchronous Server Gateway Interface

JSON: JavaScript Object Notation

SCM: Source Control Management

SSH: Secure Shell Protocol

 1

1 Introduction

As web application development has continued to progress in recent years,

developing a web application is no longer as simple as merely creating a
functional front-end and back-end. In order to build a high-performance and
stable web application, it is essential to utilize a carefully selected set of
different technologies, such as advanced web application frameworks, efficient
test automation frameworks, and sophisticated continuous integration and
deployment (CI/CD) pipelines. This thesis centres on web application
development using multiple modern technologies comprising FastAPI, Robot
Framework, and Jenkins pipeline.

FastAPI is a relatively new and powerful Python-based framework designed to

create high-performance web applications backend. It achieves this through its
asynchronous feature and intuitive API design, enabling developers to build a
robust, fast, and reliable backend that meets modern web application standards
and requirements yet spends less time in development and maintenance
processes. Jenkins on the other hand, is an automation server renowned for its
ability to streamline the continuous integration and deployment processes. It
effectively orchestrates multiple critical stages such as automated build, test,
and deployment equipping the developer team's ability to make a faster iteration
cycle of the applications development process while maintaining the integrity
and stability of the applications. This thesis also employs the Robot Framework,
which is a test automation framework widely used for the quality assurance
process. By Integrating seamlessly with Jenkins, Robot Framework helps
developers create comprehensive test cases that validate the functionality and
performance of many types of applications across various scenarios.

Last but not least, this thesis will conduct a demonstrative case study focusing
on developing, deploying, and testing a restaurant web application using
specifically the above-mentioned technologies. It aims to provide inspiration and
guidance for individuals working on their own web development projects.
 2

2 Web Applications development with FastAPI

2.1 Concept of FastAPI

FastAPI, built upon standard Python type hints, represents a modern and high-
performance web framework designed specifically for Python 3.8 and above. It is
ideal for constructing APIs with agility and efficiency. (FastAPI Authors, 2024)

Introduced in 2018 by Sebastián Ramírez, it stands out as a highly modern

Python web framework that leverages the latest advancements introduced in
Python 3 over the preceding years. It incorporates cutting-edge features that
differentiate it from traditional Python web frameworks, positioning it as a forward-
looking solution for modern web development (Bill, 2023).

FastAPI emerges as the most recent addition to Python's extensive array of web
applications frameworks (Malhar, 2023). However, it distinguishes itself as a
swift, nimble, and contemporary API framework, offering a smoother learning
experience in contrast to other Python-based web frameworks like Flask and
Django. (Abdulazeez, 2022)

2.2 Advantages and features

FastAPI is recognized as one of the "fastest" frameworks in the realm of web

development, harnessing the power of contemporary Python features to deliver
exceptional performance (Abdulazeez, 2022). FastAPI boasts a multitude of key
advantages that set it apart in the realm of web development (FastAPI Authors,
2024):

• Fast Performance: Renowned for its exceptional speed, FastAPI rivals the
performance of NodeJS and Go, thanks to its utilization of Starlette and
Pydantic. It stands as one of the swiftest Python frameworks currently
available.
 3

• Rapid Development: FastAPI could accelerates feature development

significantly, boasting an increase in speed ranging from 200% to 300%,
enabling developers to bring their ideas to life swiftly.

• Reduced Errors: By approximately 40%, FastAPI minimizes human-

induced errors, contributing to improved code quality and reliability.

• Intuitive Design: With robust editor support and comprehensive code

completion capabilities, FastAPI streamlines the development process,
reducing time spent on debugging.

• Ease of Use: FastAPI is crafted to be user-friendly and easy to learn,

reducing the need for extensive documentation reading and enabling
developers to get up to speed quickly.

• Code Conciseness: FastAPI minimizes code duplication and enhances

code conciseness, allowing multiple features to be derived from each
parameter declaration, thereby reducing the occurrence of bugs.

• Robustness: FastAPI ensures that developers can deploy production-

ready code confidently, aided by its automatic interactive documentation
and robust architecture.

• Standards-Based: Aligned with the open standards for APIs, FastAPI fully
embraces OpenAPI (formerly known as Swagger) and JSON Schema,
facilitating interoperability and adherence to industry best practices.

As the newest addition to Python's extensive array of web applications

frameworks, FastAPI provides several key features as following:

• Python type hints: Python differs from statically typed languages like
C/C++ and Java by being dynamically typed, meaning variable types are
determined by assigned values rather than explicitly declared. Unlike in
 4

C/C++/Java where variables are bound to their declared types

throughout the program's execution, Python allows variable types to
change dynamically with each assignment (Malhar, 2023).

• Asynchronous processing: Python has supported concurrent processing

using a multithreading approach since its early versions. However,
asynchronous processing support was introduced in Python starting from
version 3.5. In a multithreaded application, numerous individual threads
of operation coexist within the program, with the CPU coordinating their
concurrent execution. Conversely, in the asynchronous approach, a
single thread executes, but it possesses the capability to switch between
functions as needed (Malhar, 2023). FastAPI stands out as one of the
fastest Python web frameworks due to its integration of async code,
leveraging the ASGI support provided by the underlying Starlette
package and incorporating its own innovations. This approach enhances
performance by reducing waiting times through concurrency, a technique
utilized by other web servers through methods like threads and gevent.
(Bill, 2023)

• Automatic API documentation: FastAPI provides automatic

documentation, including interactive API documentation and exploration
web interfaces. Built on OpenAPI, it offers two default options: Swagger
UI, allowing interactive exploration and testing of APIs directly from the
browser, and an alternative API documentation with ReDoc. (FastAPI
Authors, 2024)

• Pydantic for data validation: FastAPI leverages the full range of

Pydantic's capabilities for data handling, offering developers a seamless
experience by eliminating the need to learn a new schema definition
language and ensuring compatibility with Python types. With Pydantic's
hierarchical models, support for Python typing's List and Dict, and
validators, FastAPI enables effortless validation of complex data
structures and clear documentation of JSON Schemas. (FastAPI
Authors, 2024)
 5

2.3 Structure of FastAPI applications

When developing an applications or web API, it's often impractical to contain

everything within a single file. FastAPI offers a convenient tool to organize
applications structure while maintaining flexibility. (FastAPI Authors, 2024)

Figure 1. An example file structure of simple FastAPI applications (Malhar, 2023)

The above figure shows a directory structure for a FastAPI project called
"planner". Here's what each directory and file represent:

main.py: This is the entry point of the applications where the FastAPI app
instance is created and configured. It may also contain other initialization code.

database/:

• init.py: This file marks the directory as a Python package, allowing it to

be imported

• connection.py: This file contains code related to database connection

setup and management.

routes/:
 6

• init.py: Similar to the one in the database directory, this file marks the
directory as a Python package.

• events.py: This file contains route definitions and request handling logic
related to events, which could involve creating, reading, updating, and
deleting event data.

• users.py: Similarly, this file contains route definitions and request

handling logic related to users, such as sign-up, log-in, profile
management, etc.

models/:

• init.py: Again, this file marks the directory as a Python package.

• events.py: This file contains data models or schemas related to events.

• users.py: Similarly, this file contains data models or schemas related to

users.

3 Continuous Integration and Deployment with Jenkins

pipeline

Continuous integration (CI) is the process of managing code changes and

features through a unified repository and a rigorous pipeline before merging them
into the central codebase. Continuous deployment (CD) builds on CI by
automatically releasing changes that clear all stages of the integration pipeline to
the staging or production environment. Automated testing forms a vital
component of CI/CD workflows, ensuring that rigorous quality assessments are
conducted before application deployment. The absence of automated tests could
compromise the effectiveness of CI/CD pipelines in maintaining application
quality and reliability. (Mohamed, 2021)
 7

3.1 Concept of Jenkins and Jenkins Pipelines

Originally known as Hudson, Jenkins is an open-source Continuous Integration

tool developed in Java (John, 2011). Jenkins is widely recognized for its cross-
platform compatibility and extensive support for diverse engineering
methodologies and technologies. With its robust capabilities, Jenkins caters to
organizations of varying scales, providing a versatile framework for automation.
Its rich plugin ecosystem further extends its functionality, offering limitless
automation opportunities. (Jonathan, 2015)

Figure 2. An example Jenkins dashboard (Jonathan, 2015)

The Jenkins user interface can be logically segmented into four main sections:
the Header, the Job Table, the Configuration Panel, and the Build Queue and
Executor Status Panel (Jonathan, 2015). Figure 2 depicts each of these four
content regions.

• The Jenkins header: this section provides valuable functionality and

information, encompassing UI navigation breadcrumbs, an editable
description link, an auto-refresh toggle switch, and an inclusive
contextual search solution.
 8

• The configuration panel: this section offers initial top-level configuration

choices. Each page within Jenkins has its own set of configuration panel
options, along with context-specific configuration settings.

• The job table: this section presents the defined jobs within the system
alongside fundamental status details.

• The build queue and executor status panel: this section gives an insight
into the current job executions and queued tasks within the Jenkins
system.

Jenkins Pipeline, on the other hand, is a collection of plugins designed to facilitate

the creation and management of continuous delivery pipelines within Jenkins.
These pipelines enable the automation of software delivery processes, from code
integration and testing to deployment and delivery. (Jenkins Author, 2024)

Jenkins Pipelines, when implemented in code and typically stored in source

control, empower teams to modify, review, and refine their delivery processes.
They are resilient, capable of enduring planned and unexpected Jenkins
controller restarts. Additionally, pipelines can pause, allowing for human input or
approval before proceeding with the run. They are adaptable to diverse
continuous delivery needs, enabling intricate tasks such as forking, joining,
looping, and parallel execution. Moreover, the Pipeline plugin facilitates
customization through its Domain Specific Language (DSL) and offers various
integration possibilities with other plugins. (Jenkins Author, 2024)

3.2 Jenkins pipeline development and execution

A Pipeline can be initiated through various methods (Jenkins Author, 2024):

• Using Blue Ocean: After configuring a Pipeline project in Blue Ocean, its
user interface assists in composing the Pipeline's Jenkinsfile, which can
then be committed to source control.
 9

• Through the classic UI: Users can input a basic Pipeline directly within
Jenkins via the classic user interface.

• Via SCM: Users have the option to manually create a Jenkinsfile, which
can be committed to the project's source control repository.

A Jenkinsfile is a text file housing the definition of a Jenkins Pipeline and is

committed to source control. (Jenkins Author, 2024)

Figure 3. An example Jenkinsfile (Nikhil, 2018)

Figure 3 shows a simple example of Jenkinsfile. This Jenkins Pipeline script

defines three stages—Build, Unit Test, and Publish—each with specific actions
executed sequentially to compile, test, and package a Maven project,
respectively.
 10

After creating a new Jenkins Pipeline, it is necessary to specify when Jenkins

should trigger the Pipeline job. In a Freestyle build, a build job can be triggered
in three fundamental ways (John, 2011):

• Commencing after the completion of another build job.

• Initiating builds at regular time intervals.

• Checking SCM for any modifications.

4 Automated Testing with Robot Framework

Test automation or automated testing involves utilizing software to either conduct

or aid in test activities, essentially transforming manual testing tasks into
automated processes performed by machines. (Manfred, Thomas, Marc-Florian,
Stefan, Julian & Richard, 2022.)

4.1 Concept of Robot Framework

Robot Framework, a Python-based automation framework, is designed for

Acceptance Test-Driven Development, Behaviour Driven Development, and
Robotic Process Automation, offering extensibility and a keyword-driven
approach. It thrives in distributed, diverse environments, accommodating multiple
technologies and interfaces. Surrounding the framework is a vibrant ecosystem
comprising numerous generic libraries and tools developed as distinct projects,
enriching its capabilities (Robot Framework Author, 2024). Pekka Klärck initiated
the creation of Robot Framework as a component of his master's thesis while
working at Nokia Siemens Networks in 2005. Subsequently, its second version
was released as open source under the Apache License, Version 2 in 2008, and
it now enjoys the support of a thriving community of volunteers. (Sumit, 2013)
 11

Figure 4. Robot Framework architecture (Robot Framework Author, 2024)

Robot Framework is a versatile framework that is not tied to any specific

applications or technology. As showing in Figure 4, upon initiation, Robot
Framework processes test data, runs test cases, and produces logs and
reports. The core framework remains independent of the specific target being
tested, relying instead on libraries to manage interactions with it. These libraries
may interface directly with the applications or utilize lower-level testing tools as
drivers. (Robot Framework Author, 2024)

Robot Framework offers a comprehensive suite of features designed to

streamline the test automation process and enhance testing efficiency, as
following (Robot Framework Author, 2024):

• Facilitates the creation of test cases using a straightforward tabular syntax,

ensuring uniformity.
• Allows the development of reusable higher-level keywords from existing
ones.
• Generates easily readable HTML-format result reports and logs.
• Exhibits platform and applications independence.
• Offers a straightforward library API for crafting customized test libraries,
natively implemented with Python.
• Equips a command-line interface and XML-based output files for seamless
integration into existing build infrastructure, including continuous
integration systems.
 12

• Supports a wide array of testing scenarios, including web applications,

REST APIs, mobile applications, process execution, and remote system
connectivity via Telnet or SSH.
• Enables the creation of data-driven test cases.
• Incorporates built-in support for variables, particularly useful for testing in
diverse environments.
• Implements tagging for categorizing and selecting test cases for
execution.
• Allows seamless integration with source control systems, as test suites are
simply files and directories that can be created alongside production code.
• Provides setup and teardown functionalities at both test-case and test-
suite levels.

4.2 Creating and executing Robot Framework test cases

In Robot Framework, a test file typically contains multiple sections. Different

sections are identified by a header row, and the suggested format for headers is
"*** Settings ***". However, the header recognition is flexible regarding case, the
spacing around the title, and the number of asterisks, which must be at least one
at the start. Thus, variations like "*settings" would also be recognized as a section
header. (Robot Framework Author, 2024)

Figure 5. An example Robot Framework test suite file (Robot Framework Author, 2024)
 13

The example Robot Framework test suite file from Figure 5 shows typical
sections used in most testing scenario:
• Settings: This section involves importing test libraries, resource files, and
variable files. It also includes defining metadata for both test suites and
test cases.
• Variables: This section is dedicated to defining variables that can be
utilized throughout the test data.
• Test Cases: This section involves the creation of test cases using
available keywords.
• Keywords: This section is for creating user-defined keywords based on
existing lower-level keywords.

To execute the test suite, the robot command should be used, followed by the
path to the test file. This command initiates the test process by interpreting and
running the specified Robot Framework test suite. Test cases are executed as
part of a test suite. When a test suite is created from a single file, it directly
contains test cases. However, test suites created from directories include sub-
suites, which themselves may contain test cases or further sub-suites. Typically,
all tests within a suite are run by default, but specific tests can be selected using
options like --test, --suite, --include, and --exclude. Test suites that do not
contain any tests are not considered in the execution. (Robot Framework
Author, 2024)

5 Case study

5.1 Case study summary

This case study project will illustrate the creation of a full-stack restaurant web
applications using conventional techniques HTML, CSS, and JavaScript for the
frontend, and FastAPI for the backend. Subsequently, it will showcase the
implementation of a Jenkins pipeline to automate the execution of Robot
Framework automated tests for the restaurant web applications and facilitate the
deployment process on the server. Given the extensive and longstanding use of
HTML, CSS, and JavaScript for developing web applications frontends, this
 14

aspect will not be further elaborated upon in the following sections of the case
study.

Figure 6. Case study project work flows

Figure 6 illustrates the full work flows about this case study project. Development
of source code is done locally where the frontend (using HTML, CSS, JavaScript)
and the backend (using FastAPI) are developed. Source code also includes test
suites developed with Robot Framework, which comprises graphic user interface
tests and functional tests, managed with Jenkinsfile. After local development,
changes are pushed to a GitHub repository. When the Jenkins pipeline on a
CentOS server is triggered. it will pull the source code from the GitHub repository
and subsequently execute following stages:
• First Stage: Deployment of the web applications to a testing environment
on the server.
 15

• Second Stage: Execution of the Robot Framework test suites against the
deployed applications in the testing environment on the server.
• Third Stage: Stop the applications deployed applications in the testing
environment on the server.
• Fourth Stage: If all previous stages succeed, the applications will be
deployed to the production environment on the server.

Finally, the restaurant's customers and owners are able to access the web
applications deployed to the production environment from the server.

This setup ensures that all updates to the web applications are thoroughly tested
and vetted before being made live, minimizing bugs and issues in the production
environment.

Main Objectives:

• Develop a fully functional restaurant web applications, specifically with

FastAPI serving as the backend framework.
• Develop a comprehensive set of Robot Framework test cases covering
both graphical user interface (GUI) tests and functional tests for the
restaurant web applications.
• Create and configure a Jenkins pipeline to automate the execution of
Robot Framework test cases and streamline the deployment process for
the restaurant web applications on CentOS server.

5.2 Development of web applications with FastAPI backend

This sub-section will provide a guidance on setting up a development

environment for FastAPI, creating a FastAPI applications, and elaborating on the
key functionalities of FastAPI utilized in the case study project.

Before proceeding, ensure that the system has the appropriate version of Python
installed, as FastAPI is a Python-based framework compatible with Python
versions 3.6 and above.
 16

Install FastAPI package with following command:

pip3 install fastapi

Since this FastAPI backend used in this case study project relies on several other
dependencies:
• Uvicorn: A lightning-fast ASGI server, ideal for running FastAPI
applications.
• aiomysql: An asyncio-based library for MySQL databases, allowing
asynchronous interactions with MySQL.
• pydantic: A data validation and settings management library for Python,
used heavily in FastAPI for request and response validation.
• pyjwt: A Python library for JSON Web Tokens (JWT), facilitating secure
communication and authentication.
• python-jose: A library for working with JSON Object Signing and
Encryption (JOSE) standards in Python, often used alongside pyjwt.
• python-dotenv: A Python library for parsing and loading environment
variables from .env files.
• python-multipart: A library for parsing multipart/form-data request bodies,
commonly used for handling file uploads in web applications.
The final step is to install all above-mentioned dependencies with following
command:
pip3 install uvicorn aiomysql pydantic pyjwt python-jose python-dotenv python-
multipart

Figure below shows the directory structure of FastAPI backend created in this
case study.
 17

Figure 7. FastAPI backend folder structure

• main.py - The main entry point of the applications where the application is
set up and started. It defines a FastAPI app, mounts directories for serving
static files, specifies CORS settings to manage cross-origin requests,
allowing requests from multiple predefined origins and supporting common
HTTP methods and integrates multiple routers for handling different
aspects of the applications such as login, reservation, menu, promotion,
messaging, and frontend interactions. Finally, the application is set to run
using Uvicorn as an ASGI server on port 8000, accepting connections from
all network interfaces.
 18

Figure 8. Code snippet showing file content of main.py file

• database.py – This file used for setting up database connections and

handling database operations.

Figure 9. Code snippet showing file content of database.py file

• . env - A file for environment variables that store configuration settings or

secrets, such as database host, database user, database password,
database name and secret key used for generate token.
• utils - This directory holds utility scripts that support the main applications
functionality. authentication.py handles authentication-related tasks, and
 19

basemodel.py defines base classes or schemas used across the

applications.

Figure 10. Code snippet showing file content of authentication.py file

Figure 11. Code snippet showing file content of basemodel.py file

 20

• static - This directory is used to store static files like menu images which
are used by the applications’ frontend.

Figure 12. static folder content

• routers - This folder contains different route files that define routes for the
applications. Each route file within this folder corresponds to a different
aspect or feature of the applications, handling the HTTP requests related
to that feature. Figure below shows menu creation endpoint. This endpoint
allows the uploading of a menu image along with data fields for menu
name, menu description, and menu price of a menu item. It processes the
authorization token, saves the uploaded menu image file to a static/
directory, and attempts to create a new menu item in the database using
the create_menu function.
 21

Figure 13. Code snippet showing part of the file content of menu.py file

In the folder structure shown in Figure 7, this FastAPI backend includes 6 route
files: frontend.py, login.py, menu.py, message.py, promotion.py, and
reservation.py. Each route file contains different endpoints, offering various
functionalities to the frontend. The functionalities provided by different endpoints
can be divided into 2 categories based on whether an endpoint requires
authentication token or not. The authentication token can only be acquired by an
authorized user, such as the restaurant owners, who is logged into the restaurant
web applications with valid credentials.

Restaurant customers (without authentication token) can

• review all promotions posted by restaurant owners.
 22

• make a reservation.
• send a message to restaurant owners.
• review all restaurant menus.

Restaurant owners (with authentication token) can

• login to receive a valid token.
• post new promotion, delete or modify an existing promotion.
• Post new menu, delete or modify and existing menu.
• check all message from customers, delete or mark a specific message as
acknowledged.
• check all reservations from customers, delete or mark a specific
reservation as confirmed.

5.3 Setting up Robot Framework and creating test cases

The following sub-section will illustrate the process of setting up a development

environment for Robot Framework, as well as crafting test cases for both graphic
user interface and functionality tests tailored to restaurant web applications
created in this case study project.

Just like FastAPI, Robot Framework is also a Python-based framework, meaning

that Python must be installed on the system in order to execute any Robot
Framework test case.

Install Robot Framework package with following command:

Pip3 install robotframework

Given that the test target is a web application, it's necessary to install
SeleniumLibrary as a dependency. SeleniumLibrary is indispensable third-party
library for web testing in Robot Framework, offering essential functionalities and
tailored keywords for seamless interaction with web elements during tests. It
enables testers to navigate, manipulate, and validate web applications behaviour,
ensuring reliable testing and robust functionality validation. The installation can
be done with following command:
 23

pip3 install --upgrade robotframework-seleniumlibrary

The test cases will be divided into two groups as shown in Figure 14: graphic
user interface (GUI) tests and functionality tests.

Figure 14. Robot Framework tests folder structure

The common.resource file contains numerous reusable variables and keywords

which can be used by multiple test case files.

Figure 15. Code snippet showing part of the file content of common.resource file

Figure 16. Code snippet showing part of the file content of common.resource file
 24

Figures 15 and 16 both display sections of the file content from the
common.resource file. From Figure 15, it can be seen from Settings section that
4 libraries are utilized: SeleniumLibrary for web browser automation,
OperatingSystem for system interactions, and String and DateTime libraries for
handling string manipulations and date/time operations, respectively. The
Variables section defines several key variables used in the tests: ${URL} points
to a local web application hosted at http://localhost:8000/frontend/index.html.
${BROWSER} specifies the use of a headless Firefox browser for test execution.
${TIMEOUT} establishes a default timeout of 20 seconds for test commands.
${NAVIGATION_BAR} uses an XPath locator for the navigation bar identified by
its web element id "nav". ${ALERT} is an XPath locator for message alerts using
its web element id "messageText". ${CANCEL_BUTTON} and
${DELETE_BUTTON} are XPath locators for buttons within the applications,
identified by the text they contain 'Cancel' and 'Delete'.

Code snippet from Figure 16 shows 3 examples of reusable user created

keywords. First one is “Open Web Applications”. This keyword uses another
keyword “Open Browser” from SeleniumLibrary which takes 2 parameters ${URL}
and ${BROWSER} to open a specified web applications, then it set Selenium's
speed to 0.2 seconds for operations, and wait until the navigation bar (located by
${NAVIGATION_BAR}) is present on the page. Second user created keyword
“Check Page Title” validates the page title against an expected title
${expacted_title}. It retrieves the current title using another SeleniumLibrary
keyword “Get Title” and checks if it matches the expected title, returning a
Boolean value ${page_title_correct} in the end. Third user created keyword
“Go To Home Page” facilitates navigation to the home page by clicking a web
element identified by ${HOME_TAG}. It includes steps to verify the visibility status
of 2 specific web elements “promotions list” and “reservation form” on the home
page within given time, which is specified by variable ${TIMEOUT}.

GUI_tests folder contains two test files, one for testing the GUI used by customer
and another for the GUI used by restaurant owners.
 25

Figure 17. Code snippet showing part of the file content of 01_customer_GUI_test.robot file

Figure 18. Code snippet showing part of the file content of 02_admin_GUI_test.robot file

From Figures 17 and 18, it can be observed that each GUI test file contains a
single test case, which is composed of numerous user-created keywords. Both
test cases encompass web page tests available to both restaurant owners and
restaurant customers, respectively. Each GUI test-related keyword will verify the
visibility of the corresponding web element on the respective web page at the
specified time.

Functionality tests folder contains four test files, each corresponding to a specific
aspect of the applications’ functionality: reservation, messaging, menu and
promotion.

Figure 19. Code snippet showing part of the file content of 01_reservation_test.robot file
 26

Figure 20. Code snippet showing part of the file content of 02_message_test.robot file

Figure 21. Code snippet showing part of the file content of 03_menu_test.robot file

Figure 22. Code snippet showing part of the file content of 04_promotion_test.robot file

Figures 19 to 22 show test cases defined in all four functionality test files. The
test case from each test file covers all tests related to its respective functionality.

5.4 Building the Jenkins pipeline for automated testing and deployment

This sub-section will encompass installing Jenkins on a CentOS server, creating

and configuring a pipeline, the process of triggering a pipeline job, and assessing
results obtained from a pipeline job.

Firstly, install Java on CentOS server with following command:

 27

sudo yum install java-1.8.0-openjdk-devel

Jenkins relies on Java for its operation, the presence of Java on the system is
essential for Jenkins to function.

Secondly, add Jenkins repository and import Jenkins repository GPG key with
following commands:
sudo wget -O/etc/yum.repos.d/jenkins.repohttps://pkg.jenkins.io/redhat-
stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
Jenkins isn't included in the standard CentOS repositories. To install Jenkins, it
is required to add the Jenkins repository to the system and import its GPG key to
authenticate the packages.

Thirdly, install Jenkins with following command:

sudo yum install jenkins

Fourthly, after the Jenkins installation is completed, start the Jenkins service and
configure it to launch automatically upon system boot with following commands:
sudo systemctl start jenkins
sudo systemctl enable jenkins

Lastly, access the Jenkins web interface and unlock Jenkins. The Jenkins web
interface can be accessed from the URL: http://server_ip:8080, and the Jenkins
Unlock page should open. Unlocking the Jenkins web interface requires retrieving
the initial admin password from the following path
/var/lib/jenkins/secrets/initialAdminPassword on the server. After successfully
unlocking Jenkins, it will subsequently ask to install plugins. Either install
suggested plugins or select specific plugins according to the user's particular
requirements.

Creating a Jenkins pipeline requires a series of sequential actions, each essential

for orchestrating the workflow effectively, rather than a single-click solution. The
following steps detail the process needed to establish a Jenkins pipeline tailored
specifically for the case study project.

• Click on the "New Item" link on the Jenkins dashboard.

 28

• Enter a name for the pipeline to be created and select "Pipeline" as the
project type.
• Click on "OK" to proceed to pipeline configuration.
• Now the user will be redirected to the pipeline configuration page.
• Select “GitHub project” and enter the project's GitHub repository URL.
• Choose "Build periodically" and enter “TZ=Europe/Helsinki H 5 * * 1-5” in
the Schedule input box. This schedule will execute the Jenkins pipeline
job at 5 AM Monday through Friday in the time zone set to Europe/Helsinki.
• Scroll down to the "Pipeline" section and select "Pipeline script from SCM"
as the pipeline definition method.
• Under "SCM", choose Git.
• Enter the GitHub repository URL and GitHub credentials in the
"Repositories" section.
• In the 'Branches to build' section, enter '*/main' to indicate that the 'main'
branch will be pulled from the GitHub repository when the Jenkins job is
triggered.
• Specify a local directory on the server where the GitHub repository will be
checked out and where the Jenkinsfile is located.
• Finally, click the save button to apply the configuration to the newly created
pipeline.

Next a file named Jenkinsfile need to be created. A Jenkinsfile is a text file that
defines the stage configuration of a Jenkins Pipeline. It outlines the sequence of
actions, or stages, to be executed in the pipeline. However, in Declarative
Pipelines, there is a default stage called 'Checkout SCM,' which automatically
pulls code from a version control system, such as a GitHub repository, to a
specific local directory on the server. This stage is provided by default and does
not need to be explicitly defined in the Jenkinsfile. Jenkinsfile is written in Groovy
and resides in the root directory of the project's source code repository. Script
below is the Jenkinsfile used in this case study project.

pipeline {
agent any

stages {
 29

stage('Start Applications In Testing Environment') {

steps {
catchError(buildResult: 'FAILURE', stageResult: 'FAILURE') {
script {
sh '''
#!/bin/bash
cd /home/alex/public_html/test/shell_scripts/
sudo chmod +x kill_backend_on_port.sh
backend_start_verification.sh
./kill_backend_on_port.sh 8000
sleep 5
cd /home/alex/public_html/test/backend/
sudo chmod o+w static
JENKINS_NODE_COOKIE=dontKillMe python3.9 -m uvicorn
main:app --host 0.0.0.0 --port 8000 >> /tmp/server.log 2>&1 &
sleep 5
cd /home/alex/public_html/test/shell_scripts/
./backend_start_verification.sh testing
'''
}
}
}
}
stage('Run Robot Framework Tests') {
steps {
catchError(buildResult: 'FAILURE', stageResult: 'FAILURE') {
script {
sh 'python3.9 -m robot
/home/alex/public_html/test/robot_framework_tests/'
}
}
}
}

stage('Stop Applications In Testing Environment') {

steps {
catchError(buildResult: 'FAILURE', stageResult: 'FAILURE') {
script {
sh '''
#!/bin/bash
cd /home/alex/public_html/test/shell_scripts/
./kill_backend_on_port.sh 8000
sleep 5
'''
}
}
}
}

stage('Deploy Applications To Production Environment') {

when {
expression {
println "Current build result:
${currentBuild.currentResult}"
currentBuild.currentResult == 'SUCCESS'
}
}
steps {
catchError(buildResult: 'FAILURE', stageResult: 'FAILURE') {
script {
sh '''
#!/bin/bash
echo start deploying applications to production
environment...
cd /home/alex/public_html/
sudo cp -r test /var/www/html/
cd /var/www/html/test/backend/
JENKINS_NODE_COOKIE=dontKillMe python3.9 -m uvicorn
 30

main:app --host 0.0.0.0 --port 8000 >> /tmp/server.log 2>&1 &

sleep 5
cd /var/www/html/test/shell_scripts/
./backend_start_verification.sh production
'''
}
}
}
}
}

post {
always {
step([
$class : 'RobotPublisher',
outputPath : '.',
outputFileName : "output.xml",
reportFileName : 'report.html',
logFileName : 'log.html',
disableArchiveOutput: false,
passThreshold : 95.0,
unstableThreshold : 95.0,
otherFiles : "**/*.png",
])
}
failure {
script {
sh '''
cd /var/www/html/test/backend/
JENKINS_NODE_COOKIE=dontKillMe python3.9 -m uvicorn
main:app --host 0.0.0.0 --port 8000 >> /tmp/server.log 2>&1 &
sleep 5
cd /var/www/html/test/shell_scripts/
./backend_start_verification.sh production
'''
}
}
}
}
Script 1. Jenkinsfile

This Jenkinsfile defines multiple stages for automating the deployment and
testing processes of the case study web applications on server. It starts by
stopping applications in the production environment, deploying the most recent
version of applications in a testing environment. In the next stage it runs Robot
Framework test suites based on the web applications launched in the testing
environment. After the Robot Framework tests are completed, it proceeds to stop
the applications in the testing environment. If all previous stages succeed, the
pipeline proceeds to deploy the most recent version of applications to the
production environment. Otherwise, this deployment stage will be skipped,
ensuring that problematic changes to the source code are not applied to the
applications in the production environment. The post section handles post-build
actions, such as always publishing Robot Framework test results. Additionally, if
 31

any stage fails, it restarts the web applications deployed in the production
environment without incorporating any problematic changes from the last Git pull,
guaranteeing there is always a reliable and functional version of the applications
in service. This pipeline automates the deployment and testing processes while
ensuring reliability and consistency in applications deployment.

Initiating a Jenkins pipeline job, also known as triggering, requires starting the
execution of predefined stages within the pipeline. This activation can occur
automatically through different methods like code commits, scheduled intervals,
or manual triggering.

In this case study, a time-based schedule was predefined in the pipeline

configuration process. In addition to that the pipeline job can always be triggered
manually if needed. As shown in the Figure below, the "Build Now" button is
located in the left-hand sidebar of the pipeline dashboard interface, under the
main navigation or menu. The "triggered job" information is displayed under the
"Stage View" section. This area visually represents the sequence and duration of
each pipeline stage through a grid layout. Each row in this grid corresponds to a
specific triggered job, showing the stages from checkout to post-actions, with their
respective times. The triggered jobs are identified by their unique build number,
date, and any commit changes listed on the left side under the "Build History"
section. This layout allows tracking the progress and status of each job in the
pipeline sequence very easily.
 32

Figure 23. Jenkins pipeline dashboard

In the context of Jenkins pipelines, evaluate the result from each pipeline job
typically involves analysing the outcome of the pipeline execution to determine
its success or failure. This evaluation phase assesses various factors such as
each pipeline job build status, automated tests results, and any errors
encountered during the pipeline execution. It allows users to review the
effectiveness of the pipeline, identify areas for improvement, and take appropriate
actions based on the results. Overall, the evaluation of pipeline results is crucial
for maintaining the reliability and efficiency of the continuous integration and
deployment workflow.

Each pipeline job build status will be indicate by the background colour applied
to the build number. This colour serves as a visual indicator of the job's status,
 33

providing quick insight into whether the build was successful, failed, unstable, or
aborted.
• Blue: Indicates a successful build.
• Red: Indicates a failed build.
• Yellow: Indicates an unstable build, typically meaning that although the
build completed, there were some test failures or other issues.
• Gray: Indicates a pending or aborted build.

Figure 24. The latest pipeline job’s build

As shown in the latest pipeline job's build from Figure 24, the background colour
applied to build number 122 is blue, indicating that the status of this pipeline build
is successful, meaning no errors occurred in any stage. From this pipeline job
build, the source code has been pulled from the GitHub repository. Subsequently,
the web application was successfully deployed in the test environment on the
server, and all Robot Framework test cases, based on the application deployed
in the test environment, have passed. Following this, the application was
successfully deployed in the production environment on the server. In the post-
stage, the results of the Robot tests were successfully published. What is also
satisfying is that the whole process only took less than 3 minutes, meaning it
could be significantly faster than if all stages were executed manually.

Robot Framework test results can be accessed from each pipeline job's build
page as shown from Figure 25.
 34

Figure 25. Pipeline job 112’s build page

In the Robot Test Summary section, it is evident that all six tests, encompassing
both GUI tests and functionality tests, have passed indicating this restaurant web
application is fully functioning as it was originally designed to be. More detailed
Robot Test results can be accessed by clicking the 'Open log.html' link.
 35

Figure 26. Robot Framework test log.html file

5.5 Future implementation

As mentioned in the previous chapter, the major obstacle faced in this case study
is maintain consistency of dependencies between the development environment
on the local computer and the testing and production environment on the server.

This obstacle can be effectively mitigated by employing Docker containers in this

case study project in the future. Docker is a platform that enables developers to
package, distribute, and run applications as lightweight, portable containers,
providing consistency and efficiency across different computing environments.
By encapsulating applications and their dependencies within containers, Docker
ensures that the runtime environment remains consistent regardless of the
underlying infrastructure, thereby reducing the likelihood of 'it works on local
machine but does not work on server' issues.
 36

6 Conclusion

Overall, the essential objectives of this thesis were to enhance the performance
and reliability of modern web applications and streamline the development
workflows by using integrated technologies FastAPI, Robot Framework, and
Jenkins pipeline. The case study project began with utilizing FastAPI for web
application development and crafting automated test cases with the Robot
Framework. It then progressed to automating the execution of Robot Framework
test cases for web applications and deploying the application on the server.
Whole processes clearly demonstrated the seamless integration and
effectiveness of these technologies.

Challenge of maintaining development environment consistency between local

computer and the server has been identified. However, future implementation
using Docker containers will provide a promising solution to eliminate this
challenge.

Through both theoretical insights and the successfully executed case study
project, it is anticipated that this thesis will serve as a valuable demonstrative
resource and further inspire the adoption of these techniques in more modern
web application development.
 37

References

Fastapi Authors. (2024). FastAPI Official Documentation. [Online] URL:

https://fastapi.tiangolo.com/ (Accessed: 26 March 2024)

Bill, L. (2023). FastAPI: Modern Python Web Development. [Online]. O’Reilly

Media, November 2023. URL:
https://learning.oreilly.com/library/view/fastapi/9781098135492/ (Accessed: 26
March 2024)

Malhar, L. (2023). High-Performance Web Apps with FastAPI: The

Asynchronous Web Framework Based on Modern Python. [Online]. O’Reilly
Media, March 2023. URL: https://learning.oreilly.com/library/view/high-
performance-web-apps/9781484291788/ (Accessed: 26 March 2024)

Abdulazeez A. (2022). Building Python Web APIs with FastAPI. [Online].

O’Reilly Media, July 2022. URL: https://learning.oreilly.com/library/view/building-
python-web/9781801076630/ (Accessed: 26 March 2024)

Jonathan, M. (2015). Mastering Jenkins

. [Online]. O’Reilly Media, October 2015. URL:
https://learning.oreilly.com/library/view/mastering-jenkins/9781784390891/
(Accessed: 26 March 2024)

John, S. (2011). Jenkins: The Definitive Guide

. [Online]. O’Reilly Media, July 2011. URL:
https://learning.oreilly.com/library/view/jenkins-the-definitive/9781449311155/
(Accessed: 26 March 2024)

Nikhil, P. (2018). Jenkins: Beginning Jenkins Blue Ocean: Create Elegant

Pipelines with Ease. [Online]. O’Reilly Media, December 2018. URL:
https://learning.oreilly.com/library/view/beginning-jenkins-blue/9781484241585/
(Accessed: 26 March 2024)
 38

Jinkins Authors. (2024). Jenkins Handbook. [Online] URL:

https://www.jenkins.io/doc/book/
(Accessed: 26 March 2024)

Sumit, B. (2013). Robot Framework Test Automation

. [Online]. O’Reilly Media, October 2013. URL:
https://learning.oreilly.com/library/view/robot-framework-test/9781783283033/
(Accessed: 26 March 2024)

Robot Framework Authors. (2024). Robot Framework User Guide. [Online]

URL:
https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.ht
ml (Accessed: 26 March 2024)

Mohamed, L. (2021). Pipeline as Code. [Online]. Manning Publications, October

2021. URL: https://learning.oreilly.com/library/view/pipeline-as-
code/9781617297540/
(Accessed: 26 March 2024)

Manfred, B., Thomas, S., Marc-Florian, W., Stefan, G., Julian,H. and Richard,
S. (2021). Test Automation Fundamentals. [Online]. Rocky Nook, September
2022. URL: https://learning.oreilly.com/library/view/test-automation-
fundamentals/9781681989839/
(Accessed: 26 March 2024)