# Test Framework

The purpose of this document is to describe the current Test Framework and its areas for improvement

## Test framework structure

- /test
- /[config](#`config`)
- /[data](#`data`)
- functional
- /[functional-api](#API-E2E-tests)
- /[functional-ui-e2e](#UI-E2E-tests)
- /non-functional
- /[auth](#Authorization-API-tests)
- /performance
- /[utils](Utils)
- setupTest.ts
- .env
- .travis.yaml
- .package.json
- README.md

### `config`

The `config` folder consists of multiple configurations, based on which tests are run as part of `travisCI` build

### `data`

The place where DB `snapshot` will be stored

### API-E2E-tests (execution of entities flows)
- Test Data:
- created as part of each test suite in beforeAll/beforeEach blocks
- deleted as part of each test suite in afterAll/afterEach blocks
- Execution:
- parallel (test could be executed in parallel)
- due to the behaviour of "matrix" server, the amount of parallel executed suites may need to be ajusted or excluded in separate execution configuration
- CI configuration in travis
- nightly
- realease candidate
- Utils
- mutations
- queries
- common-params
- graphql-request
- token.helper

### UI-E2E-tests (execution of entities flows)

- Test Data:
- created as part of each test suite in beforeAll/beforeEach blocks
- deleted as part of each test suite in afterAll/afterEach blocks
- Execution:
- parallel (test could be executed in parallel)
- CI configuration in travis
- nightly
- realease candidate
- Utils
- mutations
- queries
- common-params
- graphql-request
- rest-request
- token.helper

### Authorization-API-tests
- Test Data:
- test data is generated upfront test suites from a single test file start
- Tests execution flow :
- backup existing system DB,
- apply test snapshot (taken from repository) before each **auth test file**
- to execute the tests UUIDs of the entities are required, so mehanism must be in place
- due to JEST DDT functionallity limitation, the UUIDs must be ready bofore the tests initialization (beforeAll is not an option) or must be gathered with embedded query for the specific mutation parameter
- after all auth tests from a file finish, DB snapshot is restored for the next auth test file.
- after all files with auth API tests finish, system DB backup is restored
- Execution
- sequentually
- have ci configuration in travis
- nightly
- realease candidate
- Utilize
- mutations
- queries
- common-params
- graphql-request
- token.helper
- ToDo:
- increase coverage
- Utils
- mutations (defined mutations and the corresponding variable)
- queries (defined mutations and the corresponding variable)
- common-params (defined query parameters)
- graphql-request
- token.helper (gives ability to gather specific user token via client-lib)

### ToDo
1. #### API-E2E-tests
- unify the approach of sending requests (currently there are 2 approaches)
- wrapped functions containing mutation, params and request (cleaner to read and utilize)
- calling mutations through a common "mutation" method via providing the mutation string and and request parameters as params (better for maintenance)
- check the need of use of codegen (from a previous discussion it was identified that codegen requires to have the mutations specified in order to generate the code. This would result in obsolate effort for implementation and further mainenance of the tests. (TBD)
- check the possibility to use DB snapshots, (the value that it could bring is: fast execution speed; drawback: a lot of refactoring; tests will be dependent on the snapshot data)
- implement mechanism to capture `errors` when perform mutation/query

2. #### UI-E2E-tests
- increase coverage
- check for better handler of loading indicator
- add mechanism, to capture screenshot when page fails to load
- improve selectors in `client-web`

3. #### Authorization-API-tests (Top Priority)
Framework extension
- Test framework - bootstrap / teardown service
- to execute the tests UUIDs of the entities are required, so mehanism must be in place
- look at api token acquisition
- DB management - restart server after emyty DB is backup/ store backup/ wipe / createDB / restart server / / restored (add diagram)

Allow execution in nighty
- make connection to DEV/TEST env DB

- due to JEST DDT functionallity limitation, the UUIDs must be ready bofore the tests initialization (beforeAll is not an option) or must be gathered with embedded query for the specific mutation parameter
- add migration to include the users from bootstarp
- add platform level service (i.e. to run migration)