Test framework - MathparLearningTeam/Documentation GitHub Wiki

General information

Test framework is a separate project created for mathpar learning to do some integrated testing and overall work evaluation. It is written in java (Cucumber framework) with no major dependencies. It is self-sufficient (doesn't require prepared environment like created users or schools) and must leave environment untouched (clean all the created users, schools or other entities). The single project is testing all the modules at once with different scenarios for different modules.

Scenarios information

All the scenarios are located in resources/scenarios folder, logically separated by the inner folders (like account, school). Each folder contains scenarios for the appropriate feature/module but doesn't limited to it (account module can use school module endpoints if required).

Properties

Properties which are used in test framework are stored in files located in resources folder. Property files are following the "application[-profile].properties" naming convention. All the properties then loaded on startup by the PropertiesProcessor util (Java class) and stored in map for further access.

API

When the test scenario need to call API of some module, it can use API utilities defined in "mathpar.test.apis" package. API utility class uses self-written "Request" library (Spring's rest template under the hood) to send requests. Request response then is stored in special "RequestContext" class to be referenced later. Each request result is stored by the key (url) and can be accessed within a single scenario. When scenario finishes, request context is cleaned to avoid any disruption for other scenarios. Request library allows us to send requests either with or without authentication depending on the endpoint or requirement (there are no predefined set of "authenticated" request urls)

Actions

All the steps in scenario are defined in "mathpar.test.actions" package. This package has sub-packages for different modules/features. There are also generic checks defined in "CheckActions" class. Those could include "Last request finished with status xxx", "response body contains field xxx with value yyy", etc.

Contexts

Package "mathpar.test.contexts" contains different contexts for scenarios. Context contains all the information related to the specific module/feature/business logic. There are following contexts defined in an application:

  • AccountContext - contains all the information regarding the accounts used in the test scenario. This context is implemented in singleton approach for future enhancements (like concurrent tests). It also contains list of all the accounts created during the scenario so we can clean them up once the scenario is finished
  • AuthenticationContext - contains all the information regarding all the authenticated accounts. This context is implemented using static fields (should be updated to singleton, legacy code). It stores all the tokens which were issued during the scenario (after registration, after authentication etc) and also currently authenticated (chosen) token and account.
  • ProfileContext - contains all the information regarding profiles for each and every account used in scenario. This context is implemented using static fields (should be updated to singleton, legacy code).
  • RequestContext - contains all the request responses received during the scenario. It also has the shortcut for the last request response (lastRequestResult field). This context is implemented using static fields (should be updated to singleton, legacy code). Request responses are stored by the key (url of the request, think of the better key as enhancement?).
  • ScenarioContext - used as storage for persisting any information during the scenario testing. Basically it works as shared map between all the actions to store any information required for any step. This context is implemented using static fields (should be updated to singleton, legacy code)
  • SchoolContext - contains all the schools created during the scenario. This context is implemented in singleton approach for future enhancements (like concurrent tests).

All the contexts have the cleanup method which purges all the information from storages and deletes all the temporary database data from backend modules (like accounts, schools etc).

Running tests

To run the tests use the "RunCucumberTest" class. It has "tags" field available to use if not all tests should run. Without "tags" specified all the tests in scenario folder will be executed. With "tags" field specified cucumber will run through all the scenarios and check for any scenario annotated with specified tag and add them to execution list. For example, if "tags" field contains single "smoke" string, cucumber will execute all the scenarios annotated by "@smoke" decorator.