---
title: "Testing Practices"
slug: onboarding-testing-practices
section: Developer Onboarding
status: stable
description: "What \"tested\" actually means for an Alliance change, beyond a green checkmark."
last-updated: 2026-10-07
---

# Testing Practices

What "tested" actually means for an Alliance change, beyond a green checkmark.

## Overview

Testing here has three distinct layers: a local AI-slop scan, the automated test suite, and a functional verification pass that actually exercises the change against real data. All three matter — each catches a different failure mode the others miss.

## Before You Push

Run **slopgate** against your diff before pushing, not just letting CI catch it:

```
slopgate --base origin/release/<current-release>   # feature branch: the release branch it will merge into (BackOfficePrototype today: release/2026-10-globus-pilot)
slopgate --base origin/main                        # hotfix, or a release -> main PR
```

slopgate looks for AI-generated code smells — patterns that pass every conventional lint/type check but are still low-quality or subtly wrong (whole-file regenerations, misread diffs, common LLM anti-patterns). A clean local slopgate run and a clean CI slopgate run are not always the same thing — the two can drift on the tool's own version, so don't be surprised if CI flags something local didn't.

## CI Green Is Not Enough

A passing test suite and green CI checks mean your change didn't break anything the suite already covers — they don't mean the change does the right thing. The PR review process's later gates require pulling the branch and actually exercising the change against real data to confirm it returns what it's supposed to. Treat "CI is green" as a necessary precondition to ask for review, not as evidence the feature works.

## End-to-End Test Accounts

Never use your own or anyone else's real portal login to test a flow — dedicated E2E bot accounts exist for exactly this, provisioned per environment (development, QA) with known, stable states (a fresh application at the "Intake" stage, an application mid-flow, etc.). Using a real person's account risks corrupting their actual data and, if you reset their password to "test," locks them out of their real workday.

Ask the platform engineer which bot account fits the flow you're testing — the right choice depends on what state the flow needs the applicant to be in (fresh vs. mid-application vs. a specific unaccepted agreement, for example).

## Test Cases Live in Kiwi TCMS

Regression test cases are authored, reviewed and run from Kiwi TCMS at `tcms.allianceabroad.com`; the Atlas agent runs the CONFIRMED cases of its plan after every development deploy and records the results there. How to write a case, which Kiwi fields to fill, and how Atlas reads them is on [Test Case Standard (Kiwi TCMS)](/docs/test-case-standard).

## Load & Volume Testing

The scheduled load/volume testing systems were decommissioned on 2026-08-26, so there is currently no scheduled volume coverage. A manually triggered k6 workflow (Dev Load Test, `workflow_dispatch` only, suite in `scripts/loadtest/` in BackOfficePrototype) exists. If you are adding a new high-traffic endpoint, raise load testing with the platform engineer rather than assuming manual spot-checks are sufficient.

## Notes

- A test that passed yesterday and fails today on missing data is more often a seed-state problem than a regression — check the fixture/seed step before assuming your code broke something.
- "It works on my machine" locally is not equivalent to "it works in dev" — environment-specific config (secrets, feature flags, VPC connectivity) is a common source of local-only-green results.