Skip to content
juliozev edited this page Feb 12, 2019 · 30 revisions

Overview

Introduction

T-Mobile's Codeless Project is an open source Test Automation Framework that enables users to define web API and UI tests in a non-programmatic way, while leveraging application models to enable rapid development of maintainable test case automation.

Application and service models are seamlessly combined with keyword driven test definitions, to create suites of tests. Services are modeled using swagger or postman collections. UI applications are modeled using YAML based page objects. Test steps, cases, and suites are defined in excel spreadsheets, referencing model artifacts from the application under test.

High-level features

  • Model-based Testing
  • Keyword Driven Test Steps
  • Hybrid Test Cases invoking APIs and web based UIs
  • Dynamic Test Data injection with Runtime Overrides
  • Selenium Grid support for remote UI test execution

Built With

  • Java
  • Selenium
  • REST Assured
  • TestNG

Setup

  • How to setup ETP codeless test framework.

Project Structure

Project layout of framework components.

Example usage project can be viewed here (link)

  • bin directory contains the shell script executors
  • lib directory contains the framework jar, the webdrivers folder, the failedTestsScreenshots folder, and the report that is generated after the jar is executed via the script
  • models directory contains multiple folders for defining service and ui application models
  • suites directory contains the excel workbooks defining test suites
/bin
..run.bat
..run.sh

/lib
..codeless_test.jar
..ExtentReport.html
..FailedTestsScreenshots
../web_drivers

/models
../customer-service
....swagger.yaml
../order-service
....postman-collection.yaml
../online-store
....login-page.yaml
....cart-page.yaml

/suites
..regression.xlsx
..new-project.xlsx

Execution outputs

  • Extent Report: gives report for each test and test steps (request and response values of each service steps).

  • Screen Shots: Codeless framework take screenshots if a test step failed and puts it to a folder <INSTALL_ROOT>/example_usage/lib/FailedTestsScreenshots

  • Logs: For each test suite the framework generates debug log under <INSTALL_ROOT>/example_usage/logs/ folder which can be useful when triangulating issues.

Contribute

How to change library code and compile

Sub pages