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.
  • 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.
  • 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.