Structure of Unit Testing - jonasyr/gitray GitHub Wiki
βββββββ βββββββββββββββββββ ββββββ βββ βββ
ββββββββ ββββββββββββββββββββββββββββββββ ββββ
βββ βββββββ βββ ββββββββββββββββ βββββββ
βββ ββββββ βββ ββββββββββββββββ βββββ
ββββββββββββ βββ βββ ββββββ βββ βββ
βββββββ βββ βββ βββ ββββββ βββ βββ
Official Wiki of the GitRay Repository!
Table of Contents
Description
This is the Structure of Unit Testing in GitRay. This documentation shows the best practices used for unit testing.
Structure
Conventions
File names:
- Frontend tests
NameOftheRelatedFile.test.tsx
files for React components
- Backend tests
NameOftheRelatedFile.test.ts
files for services, routes, and utilities
Path:
- Backend tests
gitray/apps/backend/__tests__
- Frontend tests
gitray/apps/frontend/__tests__
Requirements
Unit Test should:
- have a code-coverage of at least 80%.
- include the Arrange-Act-Assert (AAA) pattern
- cover the Happy Path Method
Arrange-Act-Assert (AAA) pattern
The AAA pattern is a fundamental structuring method for unit tests in test automation, which is particularly widespread in Jasmine and similar test frameworks. This three-step structure follows a clear sequence that significantly increases the readability of the tests and speeds up error analysis.
- Arrange (prepare)
- In this phase, all the necessary test requirements are created:
- Instantiation of objects.
- Initialization of test variables.
- Configuration of mocks and spies.
- The definition of expected results.
- This phase often replaces redundant
beforeEach
calls.
- In this phase, all the necessary test requirements are created:
- Act (Execute)
- This section should be as short and precise as possible.
- Only the method to be tested is called here.
- Ideally, this section should consist of only a single statement to maximize test clarity and focus on the specific functionality.
- Assert (check)
- In the last step, expectations are formulated using
expect()
statements, which check the actual behavior against the expected behavior. - Here, return values, method calls or state changes can be validated.
- Multiple assertions are possible, but should test the same aspect.
- In the last step, expectations are formulated using
Happy Path Method
- For each service, implement at least tests for valid inputs, null values, empty arrays and incorrect API responses.
Explanation
- Having consistent file names and dedicated
__tests__
folders for backend and frontend makes tests easy to find and keeps contexts cleanly separated. - Enforcing β₯80% coverage ensures critical logic is exercised and signals when new code needs proper tests rather than letting gaps accumulate.
- The Arrange-Act-Assert pattern gives every test a uniform, three-step structureβsetup, execution, and verificationβso readers immediately understand whatβs being tested and why.
- Covering happy-path scenarios and edge cases (nulls, empty arrays, bad API responses) balances confidence in normal operation with resilience against failures.