...
- 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 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.
- Every spec and scenario should contain Tags. This helps in executing specific scenarios (or specs)
- The setting up of test data should be done using API calls. 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.
- Do not use plain text passwords in the test specs.