Structure of Unit Testing

   ██████╗ ██╗████████╗██████╗  █████╗ ██╗   ██╗
  ██╔════╝ ██║╚══██╔══╝██╔══██╗██╔══██╗╚██╗ ██╔╝
  ██║  ███╗██║   ██║   ██████╔╝███████║ ╚████╔╝ 
  ██║   ██║██║   ██║   ██╔══██╗██╔══██║  ╚██╔╝  
  ╚██████╔╝██║   ██║   ██║  ██║██║  ██║   ██║   
   ╚═════╝ ╚═╝   ╚═╝   ╚═╝  ╚═╝╚═╝  ╚═╝   ╚═╝   
    Official Wiki of the GitRay Repository!

Back to Home

---

Table of Contents

• Description
• Structure
  • Conventions
  • Requirements
  • Arrange-Act-Assert (AAA) pattern
  • Happy Path Method
• Explanation

Description

This is the Structure of Unit Testing in GitRay. This documentation shows the best practices used for unit testing with Vitest.

Structure

Conventions

File names:

• Frontend tests
  • NameOftheRelatedFile.unit.test.tsx files for React components
• Backend tests
  • NameOftheRelatedFile.unit.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 Vitest 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.
• 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.

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.
• Tests use the .unit.test.* naming convention to clearly distinguish unit tests from other test types.
• 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.
• The project uses Vitest as the testing framework with sophisticated coverage configuration and thread-based test execution.