Introduction

Bahmni gauge is test automation suite for Bahmni based on ThoughtWorks Gauge project. The implementation projects can leverage the commons module and can extend this framework to suit their customization requirements. The testcases written in gauge will be simple and easy to maintain. Gauge comes with a decent set of features like Specs, scenarios, steps, tags, concepts, context and many more.

Guidelines

The following are some of the guidelines that must be remembered while writing the test scenarios in Gauge. Please drop a comment on this page in case you are unclear, or discuss it on talk.bahmni.org

Every spec file should intend to test one and only one business feature. For example, new_user_registration, program_enrollment etc. The description of the spec should be clearly mentioned. This document should look like a feature documentation.
A spec file can contain multiple scenarios. Each scenario represents a test case.
Each test step should convey an intent. Do not write steps which are low level that do not convey the business intent
1. On the login page - Is the wrong way as you are not conveying a specific intent
2. Login to the application with username "test" and password "1235" - Is the correct way
Each scenario execution should be independent of others. i.e. every scenario should setup data, execute and tear down the test data. It helps in running this multiple times without worrying about previous scenarios setting up data if any. This loose coupling of scenarios helps in parallelizing the tests, and removed interdependency between tests.
The scenarios should NOT depend on the data that is already available in the database unless it comes bundled with Bahmni installation.
Every spec and scenario should contain Tags. This helps in executing specific scenarios (or specs) by tags.
The setting up of test data should be done using API calls (instead of using browser navigation). OpenMRS has a very mature API for querying/updating the database. We are relying on Unirest for posting the HTTP requests. The APIs are part of BahmniRestClient which leverages the freemarker templates. Using APIs makes the tests run faster, and stay less brittle.
Do not use plain text passwords in the test specs.
Every Page classes should extend BahmniPage and expose the methods for performing a specific functionality. These methods should have a business meaning.
1. LoginPage.login(username,password) - Is the correct way because login represents a valid business functionality
2. LoginPage.enterUsername() - Is the wrong way. This can be a private convenience method.
Do not use Sleep (or wait) methods during execution waiting for pages to load. Use synchronization. Explicit Waits are fine.
The spec file should use snake case for the filenames. The filename should outline the intent clearly. The extension of the file name should be .spec.
The code quality of Bahmni Gauge will be tracked here in codacy.

On this page

Read more about Gauge here.

Browser not supported