Skip to content

Szabolcs888/Appium2Project

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

108 Commits
logs
logs
 
 
reports
reports
 
 
scripts
scripts
 
 
src
src
 
 
test-output
test-output
 
 
.gitignore
.gitignore
 
 
README.MD
README.MD
 
 
pom.xml
pom.xml
 
 

Repository files navigation

Appium 2 Project

Java Maven Appium Selenium TestNG ExtentReports

The Appium 2 Project is a Java-based test automation framework built with Appium 2, supporting the testing of native and web mobile applications in both local and cloud-based (BrowserStack) environments.

Table of Contents

About the Project

This project was created for learning purposes, allowing me as a junior software tester to practice and deepen my knowledge in the field of test automation, particularly in testing mobile and web-based systems. I aimed to create a test framework that, in its structure and operation, resembles solutions used in professional work environments.

The framework was built entirely from scratch. The core technologies are Java, Appium 2, Selenium, TestNG, and Log4j. The system can automatically manage the Appium server, generate logs and reports (Extent Reports, as well as HTML-formatted email reports), and take screenshots in case of failure. It is also capable of uploading these artifacts to Netlify and sending them via email using the SendGrid API. Although these functions are often handled centrally in a real CI/CD environment, my goal was to understand their operation by implementing them manually, thereby learning new Java libraries and techniques.

The tests operate in a data-driven manner, with input data sourced from JSON files. During the design phase, key considerations were modularity, reusability, and easy maintainability. Code quality was also enhanced using tools like PMD and SpotBugs.

Of course, there are still countless opportunities for development and refinement. My next goals include implementing parallel test execution and CI/CD integration, for example, using Jenkins.

Testing was performed on a real Android device (Xiaomi Redmi Note 8T - Android 11) and in the BrowserStack cloud service, which I demonstrate in the videos below.

Key features and technical solutions

The project follows modern software development and test automation best practices:

  • Page Object Model (POM): UI elements and their corresponding actions are separated from the test logic, resulting in clean and maintainable code.
  • Data-Driven Configuration: Driver capabilities, environment settings, and test data are stored in external JSON and .properties files. This allows for modifying the test environment without changing the Java code.
  • Factory and Builder Design Patterns:
    • DriverFactory: A central "factory" for creating various AndroidDriver instances (native/web, local/cloud).
    • OptionsBuilder classes: Responsible for the dynamic and readable assembly of complex Appium capabilities objects.
  • POJO and Enum Classes for Structured Data Representation:
    • The system uses POJO classes (e.g., AppiumOptionsData) to read JSON configurations and test data with the help of Jackson. This provides type safety and better readability compared to raw Map objects.
    • Enums are used for the safe handling of fixed, predefined values (e.g., execution environments), preventing errors from typos.
  • Layered Logic with Steps, Assertions, and Providers:
    • Tests are broken down into well-defined layers. Page Object classes contain reusable, business-level steps (e.g., login()), while test methods are responsible for calling these steps and performing assertions.
    • Data-driven testing is supported through DataProvider classes.
  • Environment-Dependent Execution: A single configuration switch allows for toggling between local (on a real device or emulator) and cloud-based (BrowserStack) execution.
  • Programmatic Server Management: The AppiumServerManager can automatically start/stop the Appium server, eliminating the need for manual intervention.
  • Detailed Reporting: The system offers two parallel reporting mechanisms:
    • ExtentReports: Generates interactive, visual HTML reports with screenshots on failure.
    • Custom Email Reporting: Uses the SendGrid API to send HTML-formatted notifications, providing a reporting mechanism independent of any CI/CD system.
  • Timestamped Logging to File (logback): The Log4j logging system creates a separate, timestamped log file for each test run and server start, preventing log overwrites and simplifying debugging. The logging level and target location are configurable in the log4j.properties file for test runs and in config.properties for the Appium server.
  • Exception Handling with Custom Exception Hierarchy: The framework introduces dedicated custom exception classes (e.g., ConfigurationException, JsonReadException, LogFileException) all extending a base AppiumProjectException. This promotes clearer, contextualized error reporting and better maintainability.
  • Refactoring Based on the DRY (Don't Repeat Yourself) Principle: The entire project is built following the DRY principle. Frequently repeated operations—such as driver management, configuration reading, or common UI interactions—are centralized in reusable components. This significantly reduces code duplication and increases long-term maintainability.

Tech Stack

The project uses the latest or near-latest versions of the following main technologies and libraries:

  • Java 22.0
  • Maven 3.9.9
  • Appium 2.19.0
  • Appium Java Client 9.2.2
  • Selenium 4.22.0
  • TestNG 7.10.2
  • Log4j 2.24.0
  • Jackson 2.19
  • Extent reports 5.1.2
  • Sendgrid 4.10.3 (for email sending)
  • Netlify-CLI 18.0.4 (for uploading files to a server)

Tested Applications

Setup and Prerequisites

Prerequisites for Execution

  • Java Development Kit (JDK) 22 or newer
  • Apache Maven – for building the project and running tests
  • Node.js and npm – for installing and running Appium
  • Appium 2 – installed globally (npm install -g appium@next)
  • Android SDK – it is recommended to install it with Android Studio, which also provides the necessary tools and an AVD manager
  • Registration and configuration of external services:
    • Sendgrid – for sending email-based test reports. Configuration file: src/main/resources/emailsendingdata/sendgrid_account.json
    • Netlify – for public access to files in test reports (e.g., screenshots), a simple Netlify account and deploy are required
    • BrowserStack – for test execution in a cloud-based device farm. Configuration files: src/test/resources/testdatafiles/options/browserstack/

Usage and Running Tests

Configuration

  • Execution Environment and Browser: The following settings can be configured in the src/main/resources/config.properties file:
    • run.environment: The test execution environment. Possible values: local or cloud (BrowserStack).
    • browser.type: The browser used for web tests. Possible values: chrome or firefox.
  • Driver Capabilities: Platform- and environment-specific Appium settings are located in separate JSON files under the following path: src/test/resources/testdatafiles/options/appium/.

Execution Strategies and TestNG Configuration

The framework uses TestNG to configure and run tests, leveraging its advanced control features.

  • Test Suites: Predefined execution packages for various testing purposes (e.g., quick checks, full regression) are located in the src/test/resources/testng-configs/ folder. This allows running only relevant tests, optimizing time and resources.
    • smoke-tests.xml: Fast-running tests to check basic functionality.
    • regression-tests.xml: A test suite ensuring full functional coverage of the system.
  • TestNG Groups: Tests can be logically separated using the @Test(groups = {"smoke"}) annotation.
  • Data-Driven Testing (@DataProvider): The framework supports a data-driven testing approach. The DataProviderTests class for the CURA H.S. application provides an example of how to read test data (username, password) from an external JSON file (from the src/test/resources/testdatafiles/testinputs/ folder). The CuraLoginTestDataProvider class separates the data supply from the test logic, allowing the same test case to be executed with multiple input combinations.
  • Priority and Dependencies: The @Test(priority = ...) annotation allows specifying the execution order of tests, which is particularly useful for testing complex, interdependent user flows.

Running the Tests

Tests can be run in two ways – in both cases, the testng.xml suite files form the basis.

1. Running with Maven

The pom.xml file is configured with the Maven Surefire Plugin to run tests. The following commands should be executed from the project's root directory:

  • Run the default suite (based on pom.xml):

    mvn clean test

  • Run a specific suite with the -Dsurefire.suiteXmlFiles parameter:

    mvn clean test -Dsurefire.suiteXmlFiles=src/test/resources/testng-configs/testng-smoke.xml

2. Running from an IDE

Any modern Java IDE (e.g., IntelliJ IDEA or Eclipse) with TestNG support allows running tests via a graphical interface, either at the level of individual test suites or even single methods.

Screenshots of the Tests

Image 1
EndToEnd test (Sauce Labs) 		Image 2
Appointment conf. test (Cura) 		Image 3
Test on BrowserStack (Sauce Labs)

Videos of the Tests

Video 1
EndToEnd and Appointment tests (Cura) 		Video 2
EndToEnd and Cart emptying tests (Sauce L.) 		Video 3
Dropd. and Feedb. popup tests (Sauce L.)
Video 4
Smoke test (all 3 apps/run from a batch file) 		Video 5
Languages and Alarm tests (Battery Alarm) 		Video 6
Login tests with Data Provider (Cura)

License: this project is licensed under the MIT License. Created by: Szabolcs Szigli



In Hungarian

Appium 2 Project

Java Maven Appium Selenium TestNG ExtentReports

Az Appium 2 Project egy Java-alapú, Appium 2-vel készült tesztautomatizálási keretrendszer, amely natív és webes mobilalkalmazások tesztelését támogatja helyi és felhőalapú (BrowserStack) környezetben.

Tartalomjegyzék

A projektről

A projekt tanulási célból készült, hogy junior szoftvertesztelőként gyakorolhassam és mélyítsem az ismereteimet a tesztautomatizálás, különösen a mobil- és webalapú rendszerek tesztelésének területén. Olyan tesztkeretrendszert szerettem volna létrehozni, amely felépítésében és működésében hasonlít a munkahelyi környezetekben használt megoldásokhoz.

A keretrendszert teljes egészében a nulláról építettem fel. A fő technológiák: Java, Appium 2, Selenium, TestNG és Log4j. A rendszer képes automatikusan kezelni az Appium szervert, naplókat és riportokat generálni (Extent Reports, valamint HTML formátumú email-riport), illetve hiba esetén képernyőmentéseket készíteni. Ezeket képes Netlify-ra feltölteni és SendGrid API segítségével emailben továbbítani. Bár ezen funkciók egy valós CI/CD környezetben sokszor központilag vannak kezelve, célom az volt, hogy kézzel implementálva is megismerjem működésüket és ezáltal újabb Java könyvtárakat, technikákat is elsajátítsak.

A tesztek adatvezérelt módon működnek, a bemeneti adatok JSON fájlokból érkeznek. A tervezés során kiemelt szempont volt a modularitás, az újrafelhasználhatóság és a könnyű karbantarthatóság. A kódminőség javításában a PMD és a SpotBugs eszközök is szerepet kaptak.

Természetesen számtalan fejlesztési és finomítási lehetőség van még. A következő céljaim közé tartozik a párhuzamos tesztfuttatás, valamint a CI/CD integráció, például Jenkins segítségével.

A tesztelést valós Android eszközön (Xiaomi Redmi Note 8T - Android 11), valamint BrowserStack felhőszolgáltatásban végeztem, melyet fentebb videókban be is mutatok.

Főbb jellemzők és technikai megoldások

A projekt a modern szoftverfejlesztési és tesztautomatizálási best practice-eket követi:

  • Page Object Model (POM): Az UI-elemek és a velük végzett műveletek elkülönülnek a tesztlogikától, így tiszta, jól karbantartható kód jön létre.
  • Adatvezérelt konfiguráció: A driverképességek (capabilities), környezeti beállítások és tesztadatok külső JSON és .properties fájlokban találhatók. Ez lehetővé teszi a tesztkörnyezet módosítását a Java-kód megváltoztatása nélkül.
  • Factory és Builder tervezési minták:
    • DriverFactory: Egy központi "gyár", amely különféle AndroidDriver példányokat hoz létre (natív/web, lokális/cloud).
    • OptionsBuilder osztályok: A komplex Appium capabilities objektumok dinamikus és olvasható összeállításáért felelősek.
  • POJO és enum osztályok a struktúrált adatreprezentációhoz:
    • A rendszer POJO osztályokat (pl. AppiumOptionsData) használ a JSON konfigurációk és tesztadatok beolvasására, Jackson segítségével. Ez típuskontrollt és jobb olvashatóságot biztosít a nyers Map-ekkel szemben.
    • Az enum-ok a fix, előre definiált értékek (pl. futtatási környezetek) biztonságos kezelését segítik, megelőzve az elgépelésből eredő hibákat.
  • Lépésekre, asszerciókra és providerekre tagolt logika:
    • A tesztek jól definiált rétegekre bonthatók. A Page Object osztályok tartalmazzák az újrafelhasználható, üzleti szintű lépéseket (pl. login()), míg a tesztmetódusok ezek meghívásáért és az asszertálásért felelősek.
    • A DataProvider osztályok segítségével támogatott az adatvezérelt (data-driven) tesztelés.
  • Környezetfüggő futtatás: Egyetlen konfigurációs kapcsolóval válthatunk a lokális (valós eszköz vagy emulátor) és a felhőalapú (BrowserStack) futtatás között.
  • Programozott szerverkezelés: Az AppiumServerManager automatikusan képes elindítani/leállítani az Appium szervert, így manuális beavatkozás nem szükséges.
  • Részletes riportálás: A rendszer két párhuzamos riportálási mechanizmust kínál:
    • ExtentReports: Interaktív, vizuális HTML-riport, hibák esetén képernyőmentéssel.
    • Saját e-mailes riportküldés: A SendGrid API segítségével HTML-formátumú értesítés küldhető, amely független bármely CI/CD rendszertől.
  • Időbélyeges logolás fájlba (logback): A Log4j logolórendszer minden tesztfutáshoz és szerverindításhoz külön, időbélyeges logfájlt hoz létre, így elkerülhető a logfelülírás, és egyszerűbb a hibakeresés. A logolás szintje és célhelye a tesztfuttatáshoz a log4j.properties, az Appium serverhez a config.properties fájlban állítható.
  • Hibakezelés saját kivételosztályokkal: A keretrendszer több egyedi RuntimeException-leszármazott osztályt definiál (pl. ConfigurationException, JsonReadException, LogFileException), amelyek a AppiumProjectException ősosztályból származnak. Ezek az osztályok segítenek kontextusfüggőbb, jól értelmezhető hibakezelés kialakításában, és megkönnyítik a hibák naplózását és nyomon követését.
  • DRY (Don't Repeat Yourself) alapú refaktorálás: A projekt teljes egészében a DRY-elv mentén épül fel. A gyakran ismétlődő műveletek – mint például a driverkezelés, konfigurációolvasás vagy gyakori UI-interakciók – központosított, újrafelhasználható komponensekben vannak elhelyezve. Ez jelentősen csökkenti a kódismétlést és növeli a hosszú távú karbantarthatóságot.

Felhasznált technológiák

A projekt a következő fő technológiák és könyvtárak legfrissebb vagy közeli verzióit használja:

  • Java 22.0
  • Maven 3.9.9
  • Appium 2.19.0
  • Appium Java Client 9.2.2
  • Selenium 4.22.0
  • TestNG 7.10.2
  • Log4j 2.24.0
  • Jackson 2.19
  • Extent reports 5.1.2
  • Sendgrid 4.10.3 (email küldés)
  • Netlify-CLI 18.0.4 (fájlfeltöltés szerverre)

Tesztelt alkalmazások

Telepítés és előkészületek

Előfeltételek a futtatáshoz

  • Java Development Kit (JDK) 22 vagy újabb
  • Apache Maven – a projekt buildeléséhez és a tesztek futtatásához
  • Node.js és npm – az Appium telepítéséhez és futtatásához
  • Appium 2 – globálisan telepítve (npm install -g appium@next)
  • Android SDK – javasolt az Android Studio-val együtt telepíteni, amely biztosítja a szükséges eszközöket és AVD-kezelőt is
  • Külső szolgáltatások regisztrációja és konfigurálása:
    • Sendgrid – e-mail alapú tesztriportok küldéséhez. Konfigurációs fájl: src/main/resources/emailsendingdata/sendgrid_account.json
    • Netlify – a teszt reportokban szereplő fájlok (pl. screenshotok) nyilvános eléréséhez egy egyszerű Netlify-fiók és deploy szükséges
    • BrowserStack – felhőalapú eszközparkban való tesztfuttatáshoz. Beállítási fájlok: src/test/resources/testdatafiles/options/browserstack/

Használat és tesztek futtatása

Konfiguráció

  • Futtatási környezet és böngésző: Az src/main/resources/config.properties fájlban adhatók meg az alábbi beállítások:
    • run.environment: A tesztek futtatási környezete. Lehetséges értékek: local (helyi gépen) vagy cloud (BrowserStack).
    • browser.type: A webes tesztekhez használt böngésző. Lehetséges értékek: chrome vagy firefox.
  • Driver képességek (capabilities): A platform- és környezetspecifikus Appium-beállítások külön JSON-fájlokban találhatók a következő útvonalon: src/test/resources/testdatafiles/options/appium/.

Futtatási stratégiák és TestNG-konfiguráció

A keretrendszer a TestNG tesztkeretrendszert használja a tesztek konfigurálásához és futtatásához, kihasználva annak fejlett vezérlési lehetőségeit.

  • Test Suite-ok: A különféle tesztelési célokra (pl. gyors ellenőrzés, teljes regresszió) előre definiált futtatási csomagok találhatók az src/test/resources/testng-configs/ mappában. Ezek lehetővé teszik, hogy csak a releváns teszteket futtassuk, optimalizálva az időt és az erőforrásokat.
    • smoke-tests.xml: Alapfunkcionalitást ellenőrző, gyors futású tesztek.
    • regression-tests.xml: A rendszer teljes körű funkcionális lefedettségét biztosító tesztcsomag.
  • TestNG-csoportok (groups): A tesztek @Test(groups = {"smoke"}) annotációval logikailag elkülöníthetők.
  • Adatvezérelt tesztelés (@DataProvider): A keretrendszer támogatja a data-driven testing megközelítést. A CURA H.S. alkalmazás DataProviderTests osztálya példát mutat arra, hogyan olvashatók be a tesztadatok (felhasználónév, jelszó) külső JSON fájlból (a src/test/resources/testdatafiles/testinputs/ mappából). A CuraLoginTestDataProvider osztály különválasztja az adatszolgáltatást a tesztlogikától, így ugyanaz a teszteset több bemeneti kombinációval is végrehajtható.
  • Prioritás és függőségek: A @Test(priority = ...) annotáció lehetővé teszi a tesztek futtatási sorrendjének megadását, ami különösen hasznos összetett, egymásra épülő felhasználói folyamatok tesztelésekor.

Tesztek indítása

A tesztek futtatása kétféleképpen történhet – mindkét esetben a testng.xml suite-fájlok képezik az alapot.

1. Futtatás Maven segítségével

A pom.xml fájlban konfigurált Maven Surefire Plugin gondoskodik a tesztek futtatásáról. A következő parancsokat a projekt gyökérkönyvtárából kell kiadni:

  • Alapértelmezett suite futtatása (a pom.xml alapján):

     mvn clean test

  • Konkrét suite futtatása a -Dsurefire.suiteXmlFiles paraméterrel:

    mvn clean test -Dsurefire.suiteXmlFiles=src/test/resources/testng-configs/testng-smoke.xml

2. Futtatás IDE-ből

Bármely modern Java IDE (pl. IntelliJ IDEA vagy Eclipse) támogatja a TestNG-t, így grafikus felületen keresztül is indíthatók a tesztek, egyéni test suite-ok vagy akár egyes metódusok szintjén.

Licenc: Ez a projekt az MIT-licenc alatt érhető el. Készítette: Szabolcs Szigli

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

4 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages