Skip to content

Testing Strategy 1.0 #157

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hcarreras wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Testing Strategy 1.0 #157

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 0 additions & 45 deletions technical_practices/tdd_testdriven_development.md
View file
Open in desktop

This file was deleted.

41 changes: 41 additions & 0 deletions technical_practices/testing_strategy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Testing Strategy

This document outlines Abtion's testing expectations and requirements across all projects.

## General Expectations

### Critical Flows
All critical flows must have end-to-end (e2e) tests. These tests ensure that the most important user journeys work correctly from start to finish.

### Bug Fixing
Every bug fix must include a new test that:
- Reproduces the bug scenario
- Verifies the fix works correctly
- Prevents regression in the future

### CI Requirements
**CI cannot merge if red** — this is non-negotiable.

All tests must pass before code can be merged. No exceptions.
Comment on lines +17 to +19
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

These two statements are slightly redundant. The first statement, 'CI cannot merge if red — this is non-negotiable', already implies that all tests must pass. You could combine them for conciseness and impact.

Suggested change
**CI cannot merge if red** — this is non-negotiable.
All tests must pass before code can be merged. No exceptions.
**CI pipelines must pass before merging.** A failing (red) pipeline is a hard block, and this rule is non-negotiable.


---

## Backend

### Test Coverage
- **80% test coverage** is enforced as a CI rule
Copy link
Contributor Author

@hcarreras hcarreras Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 100% test coverage
  • Allow skipping lines by just adding a comment explaining why it is skipped.

Copy link
Contributor Author

@hcarreras hcarreras Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Branch coverage.

- Coverage gates are mandatory and will block merges if not met
Comment on lines +26 to +27
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

These two points are redundant. 'Enforced as a CI rule' already implies that mandatory coverage gates will block merges. You can combine them into a single, more concise point.

Suggested change
- **80% test coverage** is enforced as a CI rule
- Coverage gates are mandatory and will block merges if not met
- A minimum of **80% test coverage** is enforced through mandatory CI gates that block merges if the threshold is not met.


---

## Frontend

### Test Coverage
**80% test coverage** is required for:
- Utils
- Validation logic
- Data mapping functions

### UI Testing Approach
- **Don't unit test the UI** — avoid testing implementation details of visual components
- **Test component logic** — focus on behavior, state management, and business logic within components
Comment on lines +40 to +41
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The statement 'Don't unit test the UI' is very absolute and could be misinterpreted. While the intent to avoid testing implementation details is correct, this phrasing might discourage valuable component-level testing. Consider rephrasing to emphasize testing behavior over implementation, which seems to be the core message of these two points.

Suggested change
- **Don't unit test the UI** — avoid testing implementation details of visual components
- **Test component logic** — focus on behavior, state management, and business logic within components
- **Test behavior, not implementation details.** UI tests should focus on what the component does from a user's perspective (behavior, state changes, business logic) rather than its internal structure. This creates more robust and less brittle tests.