Build Regression Test Suite

[Kalchaqui]

Issue: Build Regression Test Suite

Depends on: Existing Jest test infrastructure (jest.config.js, existing *.spec.ts files)

Task Description

Create a Regression Test Suite so previously resolved production issues cannot silently reappear. Every fixed bug should ship with a regression test that references its originating issue/PR.

Deliverable

A dedicated regression suite integrated into the backend testing pipeline, organized so each test is traceable to the bug it guards.

Requirements

Create regression tests for:

• Previously fixed bugs (with issue/PR reference in the test description).
• Agreement synchronization issues (webhook status mapping — e.g. escrow.released must set completed, not stay funded).
• Validation failures (e.g. dispute payer_percentage + payee_percentage = 100; invalid Stellar address rejected).
• Status transition bugs (illegal transitions blocked; correct previous_state → new_state).
• Activity logging bugs (transitions and dispute events land in agreement_activity).
• API edge cases (invalid JWT, not-found IDs, unauthorized wallet on by-wallet / mutations).

Each regression test must document its related issue.

Validation System

• Every listed bug category has at least one regression test tied to a real issue/PR.
• Re-introducing a known bug locally makes the corresponding test fail.
• The suite runs green in CI.

Technical Requirements

• Tests are independent (no shared mutable state; mock Supabase/TW).
• Execute in CI via pnpm test (testRegex: .*\.spec\.ts$).
• Include a bug/issue reference in each describe/it title or a header comment.
• Easy to extend via a clear convention (*.regression.spec.ts, or a src/**/regression/ / __regression__ folder).

Additional Notes

Adopt a policy: future bug fixes are not "done" until a corresponding regression test exists. Suggested convention: colocate as *.regression.spec.ts so they're discoverable but distinguishable from unit specs.

Testing (required)

• At least one regression spec per bug category listed above.
• Each spec references its issue/PR in the title or header comment.
• Independence check: specs pass when run in isolation and in any order.
• CI runs the regression specs as part of pnpm test.

Proof of Completion (required)

• Link the merged PR.
• Paste the passing CI output showing the regression specs.
• Provide a short index (table) mapping each regression test → the issue/PR it guards.
• Link to the documented "fix requires a regression test" policy (README/CONTRIBUTING).

[olaleyeolajide81-sketch]

I would love to work on this issue

[diegoTech14]

Hello Thalos team I'd love to work on this issue. 👋

Background

I'm a backend developer with ~3 years of experience in Node.js/TypeScript and payment/fintech systems, and a top-10 contributor on OnlyDust with 50+ merged PRs across 15+ projects. I work daily with multitenant backends where regression coverage is critical — I've built test suites around stored procedures, validation layers, and status-transition flows, so this task maps directly to my day-to-day work.

How I would approach it

1. Audit fixed bugs: Review closed issues and merged bug-fix PRs to build an inventory of previously resolved problems (agreement sync, validation failures, status transitions, activity logging, API edge cases).

2. Create a dedicated suite: Add a tests/regression/ directory, organized by domain:

   • agreement-sync.regression.test.ts
   • validation.regression.test.ts
   • status-transitions.regression.test.ts
   • activity-logging.regression.test.ts
   • api-edge-cases.regression.test.ts

3. Traceability: Each test documented with a JSDoc header referencing the original issue/PR:

   /**
    * Regression test for #123 — Agreement status desync after concurrent updates
    * Fixed in PR #130
    */

4. Independence: Each test sets up and tears down its own fixtures (no shared state, no execution-order dependencies), so tests can run in isolation or in parallel.

5. CI integration: Add a test:regression script and wire it into the existing CI workflow so the suite runs on every PR.

6. Extensibility: Include a README.md in the regression folder with a template and contribution guide, so future bug fixes can add their regression test following a clear convention — supporting the "no fix is complete without a regression test" policy.

Thanks for considering my application! 🚀

[OpensrcLord]

Hello @maintainer, I understand the expected outcome and would love to work on this. I'll provide a solution that satisfies the acceptance criteria.

[Cbiux]

Hi! I'm Sebastian, and I'd love to collaborate on this issue.

My approach would be to introduce a dedicated Regression Test Suite integrated into the existing backend test pipeline. I would organize regression tests by bug category (agreement synchronization, validation, status transitions, activity logging, and API edge cases) while ensuring each test is isolated, deterministic, and CI-friendly.

Additionally, every regression test would include a reference to the original issue or bug it addresses, making it easy to trace why the test exists and preventing future regressions. The suite would also be structured so new regression tests can be added with minimal effort as new production bugs are resolved.

Looking forward to contributing!

Blessings.

[grantfox-oss]

🦊 GrantFox — @Cbiux has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #69)
2. Your PR will be reviewed by the Thalos-Infrastructure maintainers

Good luck! Track your progress on GrantFox.

[ManuelJG1999]

🎉 Congratulations @Cbiux ! This issue has been assigned to you.

Before you start, make sure you understand the requirements. If you have any questions, ask us in our community chat:
https://t.me/ThalosOSSCommunity

Please keep us updated on your progress. If there's no activity or communication within 48 hours, the issue may be reassigned to another contributor.

Happy coding, and thanks for contributing to Thalos! 🐉

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@Cbiux's PR #126 was approved and merged by @Kalchaqui.

🏆 @Cbiux: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (274 total points). Track your full progress on GrantFox.

👏 Great work, @Cbiux! Keep contributing to Thalos-Infrastructure.