The Gears framework is made to let your team test defective web applications without digging in their internals. You will not have to learn scripting, you will not have to learn xpath, html or css syntax. You will not have to spend hours tweaking a click action on a badly-designed button. This tool will handle all this work and let you focus on the testing mind-work. Our goal is to make test automation intuitive effort, rather than a technical experience. We want simple stuff to be done simply and naturally with little or no technical skills.

If you want to run functional regression tests on an enterprise web-application and you have a large team of business-savvy testers, this is the tool for you. On the contrary if your team is a few technically experienced automation engineers, you might be better off with traditional automation tools or even tailoring your own framework based on free tools like WebDriver.

Note: this is an early version of Gears, while some functionality is planned, designed or mocked it might not be available yet - see comments below.

Table of content

1. Gears Debugger
2. Scenario formats

Gears Debugger

The Debugger is the main user interface for Gears library. In it's essence is similar to what Selenium IDE or practically all commercial automation tools provide. It allows you to step through your scenario and actually build it on the fly. The debugger provides basic command-line interface to control the flow of your scenario and can reload any changes you make to the scenario. You can also invoke keywords ad-hoc via explicit commands.

The difference between Gears debugger and traditional tools is that it feeds plain language. So technically it is planned as simple console app so it can process sentence commands from text files or voice input. This doesn't have to be actually a test of an application, it can also be as simple a command as to order a pizza or to text message to a friend.

Note: currently the scope is keyword-driven functional regression testing of enterprise web-apps, plaintext control and similar assistance functionality is coming in later versions.

Parameters

The debugger is an .exe application which currently expects a File-name of your scenario's file as it's parameter. This file can be an Excel file or CSV and has to be of a specific format (see Scenario formats below). There is a generic batch file distributed with the binaries which already links to a default sample test (also part of the dist), however you can easily create a batch file yourself.

Note: Scenario formats are to be available in other formats including website hosted content (e.g. JIRA test cases) while Gears will provide means to integrate these.

Scenario formats

The main format of scenario definition is a table where each line represents one step and each row represents an input parameter type. First column always contains the type(or class-name) of the step that is to be executed.

Here's an example:

Discriminator	Url	What	Where
GoToUrl	www.google.com
Click		Search

Note that the first column needs to be named 'Discriminator' and the entire row content is case-sensitive. The values however are not case-sensitive i.e. 'Click Seach' will work as well as 'Click sEaRCh'.

The rest of the columns determine parameters for each step. Empty cell means it will be ignored. As each keyword can accept various combination of parameters, you have to refer to the Library documentation below.

While technically it is possible to write any scenario using the default keywords distributed with the application, we will provide a mechanism for users to extend the library themselves both by hierarchy of excel sub-scenarios as well as by scripting new keyword classes directly using the Gears API.

Note: Extending keywords is not yet available.