Welcome to Squash TF components documentation!¶
This new documentation site is under construction. Some sections are still missing. We will complete them in the following weeks.
Squash Test Factory (aka Squash TF) is a set of components whose purpose is to help you implement and run the automated tests of your projects.
A typical cycle to create an automated test has 3 phases:
- Phase 1: Describe the test to achieve
- Phase 2: Implement the automated test based on the description done in Phase 1
- Phase 3: Run the test implemented in phase 2
Squash TF is focus on phase 2 and 3. If you want to address the full cycle, our brother project Squash TM (Squash Test Management) is a good solution for phase 1. (Moreover a bridge exist between Squash TF and Squash TM)
Our goal is :
- to be able to run your tests whatever the technology you used to implement them
- to facilitate the run of your tests on multiple environments
- offer a solution which allows the use of multiple test stacks in one test
- bring tools easy to integrate in CI/CD pipelines
The run phase¶
The Run phase is supported by Squash TF Execution Server
It is based on jenkins and its distributed build capabilities (for multi environments execution). Base our execution server on Jenkins bring us :
- all the features of the jenkins ecosystem ( scm connectors, master/agent mode, pipeline, …)
- facilitate the integration in CI/CD pipelines
We distribute Squash TF Execution Server in two ways:
- as installer for windows and linux
- as docker image for linux
The implementation Phase¶
For the implementation phase, there is 3 ways to do it :
- Use a pure code approach (with or without frameworks)
- Use a dedicated studio like Robot Framework or Katalon
- Use our implementation solution : Squash Keyword Framework
Whatever way you choose to implement your automated tests, we want to be able to execute them in Squash Execution Server
Pure Code & dedicated studio approach
For people which :
- already have automated tests written
- used specific technology (like their own test robot)
When automated tests are already (will be) written in pure code or with a dedicated studio we need a solution to run them as seamless as possible. To this purpose we decided to create runners.
Runners main goal is to run automated tests in our ecosystem and also ensure the link with our brother project Squash TM for execution of test not written with Squash Keyword Framework. Runners have to :
- manage the test suites to execute (with filter or json)
- launch the executions
- manage the the reports creation
- when linked with Squash TM * report tests execution status to Squash TM * send execution reports to Squash TM
As Squash TF is mainly written in Java, we have started by creating two runners tight to Java :
Our implementation : Squash Keyword Framework
We have also created our own implementation stack called Squash Keyword Framework, which is a keyword test framework using, most of the time, existing Robots. This framework includes a DSL for writing automated tests scripts and an engine to execute the scripts. It allows the use of multiple robots in one single test.
> Keyword test framework
In a keyword tests framework :
- test scripts are a composition of keywords
- keywords are small blocks of reusable features
- the framework provides a library of default keyword.
In Squash Keyword Framework :
- keywords are made of macros
- a large set of built-in macros is provided
- macros can be combined to create a higher level macro
- macros could also be created by using low level instructions, if needed
> Engine with plugins
At the heart of our framework, there is an engine which using plugins to pilot test robots. For each robot, a plugin (connector) has been created which provides :
- the built-in macro
- the low level instructions and their implementation (to pilot the robot).
The Squash Keyword Framework plugin architecture makes it an expandable solution : you can contribute by creating a new plugin for a new robot (or by extending an existing one). See community section for contribution.