Introduction
Bahmni gauge is test automation suite for Bahmni based on ThoughtWorks <=
a class=3D"external-link" href=3D"http://getgauge.io" rel=3D"nofollow">Gaug=
e project. The implementation projects can leverage the commons module and can extend=
this framework to suit their customization requirements. The testcas=
es 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
- Every s=
pec file should intend to test one and only one business feature.  =
;For example, new_user_registration, program_enrollment etc. The desc=
ription 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 c=
ase.
- Each test step=
a> should convey an intent. Do not write steps which are low level th=
at do not convey the business intent
- On the login page - Is the wrong way as you are not conveying a=
specific intent
- Login to the application with username "test" and password "1235" - Is the correct way
- Each scenario execution should be independent of others. i.e. eve=
ry scenario should setup data, execute and tear down the test data. I=
t helps in running this multiple times without worrying about previous scen=
arios setting up data if any. This loose coupling of scenarios helps in par=
allelizing the tests, and removed interdependency between tests.
- The scenarios should NOT depend on the data that is already available i=
n the database unless it comes bundled with Bahmni installation.
- Every spec and scenario should contain Tags. This helps in executing specific sce=
narios (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/updat=
ing the database. We are relying on Unirest for posting t=
he HTTP requests. The APIs are part of BahmniRestClient which leverages the freemarker templates. Usin=
g 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 BahmniPag=
e and expose the methods for performing a specific functionality.  =
;These methods should have a business meaning.
- LoginPage.login(username,password) - Is the correct way because=
login represents a valid business functionality
- 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 t=
o load. Use synchronization. Explicit Waits are fine.
- The spec file should use snake case for the file=
names. The filename should outline the intent clearly. The exte=
nsion of the file name should be .spec.
- The code quality of Bahmni Gauge will be tracked here in codacy.