Test Strategy

Test StrategyStrategy: Drop — Fintech Payment App

Project: {{PROJECT_NAME}}Drop — Remittance + QR Payments Version: {{VERSION}}1.0 Date: {{DATE}}2026-02-23 Author: {{AUTHOR}}John (AI Director) Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}}Alem Bašić (CEO)

Document History

Version	Date	Author	Changes
0.1	{{DATE}}2026-02-23	{{AUTHOR}}John	Initial draftstrategy — aligned to Drop tech stack (Vitest + Playwright)

---

1. Testing Philosophy & Principles

Core Principles:

1. Tests are first-class code — reviewed, maintained, refactored like production code
2. Test the behavior, not the implementation — tests enable safe refactoring
3. Fast feedback — unitunit/integration tests run in seconds; blocking tests run in < 53 minutes
4. Tests document intent — a failing test explains what broke and why it matters
5. Shift left — find bugs as early as possible, before they reach users
6. Security-by-testing — all security invariants (no balance column, no CVV, bcrypt-only) are encoded as automated tests

Testing philosophy: {{PHILOSOPHY}}Drop follows the test pyramid with a fintech-specific emphasis: critical financial invariants (no stored balances, PCI-DSS compliance, pass-through model) are verified in the unit/integration layer on every commit. E2E tests cover the 5 critical user journeys (registration, login, remittance, QR payment, merchant registration). We do not aim for 100% E2E coverage — instead we validate the most valuable and highest-risk paths.

---

2. Test Pyramid

pyramid
    title Test Distribution
    accTitle: Test Distribution by Layer
    "Unit Tests (70%)" : 70
    "Integration Tests (20%)" : 20
    "E2E Tests (10%)" : 10

graph TB
    subgraph E2E["E2E Tests — 10%Playwright (3 projects)"]
        E2E_DESC["Critical5 critical user journeys<br/>Browseruser-flows /+ APIfull-flows end-to-end+ input-chaos<br/>Slow, expensive, high-confidence"]
    end
    subgraph INT["Integration Tests — 20%Vitest (api-endpoints, db, middleware)"]
        INT_DESC["Service-to-serviceAPI request/response contracts<br/>DB +schema cacheintegrity + externalFK APIsconstraints<br/>MediumRate speed,limiter high-value"+ auth middleware"]
    end
    subgraph UNIT["Unit Tests — 70%Vitest (auth, validation, transactions)"]
        UNIT_DESC["Functions,bcrypt classes,hashing, modulesJWT verification<br/>PureFee businesscalculations, logicinput validation<br/>Fast, cheap, developer-owned"]
    end
    subgraph PERF["Performance Tests — Vitest benchmarks"]
        PERF_DESC["api-benchmarks.test.ts<br/>bcrypt timing, query latency<br/>50 concurrent rate limit calls"]
    end

2.1 Unit Tests

Attribute	Value
Scope	Individual functions,functions: classes,auth purehelpers, businessfee logiccalculators, input validators
External dependencies	Mocked (no real DB, network,no orreal filesystemBaaS, calls)no real Sumsub)
Framework	{{UNIT_FRAMEWORK}}Vitest (via npm run test)
Coverage target	≥ {{UNIT_COVERAGE}}%80% lines,overall; ≥100% {{BRANCH_COVERAGE}}%for branchesauth + transaction paths
Execution time	Full suite < {{UNIT_TIME}}30 minutesseconds
Runs on	Every commit, pre-commit hookhook, CI
Written by	DeveloperBuilder whoagent writes(Claude theSonnet) feature+ reviewed by Validator

What to unit test:

• BusinessverifyPassword logic— andbcrypt algorithmscorrectness; SHA-256 hash rejection
• EdgesignJWT cases/ andverifyJWT error— conditionsJWT signing, tampered token rejection
• DataFee transformationscalculation and— validations0.5% remittance fee, 1% QR fee
• UtilityInput functionsvalidation — age ≥ 18, Norwegian phone (+47), password length, XSS/injection rejection

What NOT to unit test:

• Framework boilerplate (Next.js API routes scaffolding)
• Third-party library internals (jose, bcrypt)
• Simple propertydata getters/settersfetching with nowithout logic
• Framework boilerplate

2.2 Integration Tests

Attribute	Value
Scope	ServiceAPI interactions:endpoints, DB,DB cache,schema, messagemiddleware queues,(rate internallimiter, APIsauth middleware)
External dependencies	Real (test containers or sharedSQLite test environment)DB; mock BaaS (NEXT_PUBLIC_SERVICE_MODE=mock)
Framework	{{INT_FRAMEWORK}}Vitest
Coverage target	All service26 boundariesAPI routes tested; ≥all {{INT_COVERAGE}}%DB ofinvariants integration pathsasserted
Execution time	Full suite < {{INT_TIME}}2 minutes
Runs on	Every PR, blocking merge
Written by	DeveloperBuilder whoagent writes+ the integrationValidator

What to integration test:

• Databaseapi-endpoints.test.ts queries— andall ORM26 mappingsroutes: status codes, response shapes, auth gating
• APIdb.test.ts endpoint— request/responseschema contractsinvariants: no balance column, no card_number/cvv, FK constraints, transaction type enum
• Messagemiddleware.test.ts queue— publish/consumerate limiting (10 req/min auth; 429 on 11th); JWT auth; CSRF protection
• Cacheauth.test.ts read/write— behavior
bcrypt
• Authenticationrounds middleware12; SHA-256 rejection; JWT tampered token rejection

2.3 E2E Tests

Attribute	Value
Scope	Critical user journeys through the real deployedstaging applicationenvironment
External dependencies	Real (staging environment)(https://drop-staging.fly.dev/) with mock BaaS
Framework	{{E2E_FRAMEWORK}}Playwright (3 projects: user-flows, full-flows, input-chaos)
Coverage target	Top {{E2E_JOURNEY_COUNT}}5 critical userjourneys; journeysinput-chaos covers 20+ validation edge cases
Execution time	Full suite < {{E2E_TIME}}10 minutes
Runs on	Post-staging deploy, pre-production gate
Written by	QA + DeveloperBuilder agent collaboration

Critical journeys tocovered E2Eby test:E2E:

1. {{JOURNEY_1}}User registration (3 steps: email+DOB → OTP → PIN)
2. {{JOURNEY_2}}User login + dashboard access
3. {{JOURNEY_3}}Remittance (NOK → RSD/BAM/PKR/TRY/PLN/EUR)
4. QR payment (scan → confirm → receipt)
5. Merchant registration + QR code generation

---

3. Testing Tools

Type	Tool	Version	Purpose	Config File
Unit testing+ Integration	{{UNIT_TOOL}}Vitest	{{VERSION}}2.x	UnitUnit/integration tests	{{CONFIG_PATH}}vitest.config.ts
TestE2E runnertesting	{{RUNNER}}Playwright	{{VERSION}}1.x	ParallelBrowser executionE2E (3 projects)	{{CONFIG_PATH}}playwright.config.ts
Coverage	Vitest (@vitest/coverage-v8)	Built-in	Coverage reports	vitest.config.ts
Performance	Vitest (bench)	Built-in	Benchmark tests	api-benchmarks.test.ts
Mocking	{{MOCK_TOOL}}Vitest (vi.mock)	{{VERSION}}Built-in	Mock BaaS, Sumsub, external deps	Built-in
Integration testingCI/CD	{{INT_TOOL}}GitHub Actions	{{VERSION}}—	IntegrationAutomated testsCI pipeline	{{CONFIG_PATH}}
Test containers	{{CONTAINER_TOOL}}	{{VERSION}}	Real DB/Redis in tests	{{CONFIG_PATH}}
E2E testing	{{E2E_TOOL}}	{{VERSION}}	Browser E2E	{{CONFIG_PATH}}
Coverage	{{COV_TOOL}}	{{VERSION}}	Coverage reports	{{CONFIG_PATH}}
Performance testing	{{PERF_TOOL}}	{{VERSION}}	Load/stress tests	{{CONFIG_PATH}}
Visual regression	{{VIS_TOOL}}	{{VERSION}}	UI screenshot diff	{{CONFIG_PATH}}.github/workflows/

---

4. Test Environments & Data Management

Test Environments

Test Type	Environment	Database	External Services
Unit	Local (no env)	None / in-memory	Mocked via vi.mock
Integration	Local + DockerCI	TestContainersSQLite test DB (:memory: or temp file)	StubbedMock BaaS (NEXT_PUBLIC_SERVICE_MODE=mock)
E2E	Staging (Fly.io, Stockholm)	DedicatedStaging testSQLite DB/ PostgreSQL	Sandbox/testMock modeBaaS + Mock Sumsub
Performance	StagingLocal (production-sized)api-benchmarks.test.ts)	Production-scale dataSQLite	SandboxMock

Test Data Management

usereal

Approach	Used For	Tool	Notes
Fixtures /in factoriestest files	Unit + integration tests	{{FACTORY_TOOL}}Vitest beforeEach/afterEach	Reset per test
Database seeding	E2E tests	scripts/seed.shnpm run db:seed	Reset per test run
AnonymizedSynthetic productionseed data only	All tests	Hardcoded test data	PerformanceNEVER tests	scripts/anonymize.sh	Weeklyuser refreshdata (NFR-D04)
Shared test accounts	E2E (cross-service)consumer + merchant roles)	TestVaultwarden account"Drop vaultUAT" entries	Never modified by tests

Data cleanup policy: All test data cleaned up after test run (via Vitest afterEach teardown hookshooks. orSQLite transactiontest rollback)DB wiped between runs.

---

5. Test Automation Strategy

db.test.ts

Test Type	Automation	Trigger	Tooling
Unit tests	100% automated	Pre-commit + CI	{{UNIT_TOOL}}Vitest
Integration tests	100% automated	CI on PR	{{INT_TOOL}}Vitest
E2E (critical paths)	100% automated	Post-staging deploy	{{E2E_TOOL}}Playwright
E2E (edge cases)input-chaos)	Partially100% automated	WeeklyPost-staging scheduled rundeploy	{{E2E_TOOL}}Playwright input-chaos project
Performance tests	Automated baseline	WeeklyEvery +CI pre-releaserun	{{PERF_TOOL}}Vitest benchmarks (api-benchmarks.test.ts)
Security (SAST/SCA)SAST)	100% automated	Every PR	{{SAST_TOOL}}GitHub Actions + npm audit
VisualDB regressioncompliance	Automated100% automated	OnEvery UI changescommit	{{VIS_TOOL}}
Accessibility	Automated + manual	On UI changes	{{A11Y_TOOL}}(Vitest)
Manual exploratory	Manual	SprintPre-release end / pre-releaseUAT	—CEO (Alem)

---

6. Manual Testing Scope

Manual testing is required for:

• NewCEO feature(Alem) exploratoryUAT walkthrough before Phase 1 production launch
• BankID SCA flow (Phase 2 — not yet integrated)
• Real BaaS payment flow (Phase 2 — mock only in MVP)
• Mobile device testing on physical iOS/Android hardware (firstPlaywright sprintcovers of375px a feature)
• Usability and UX reviewviewport)
• Accessibility testingusability (beyondon automatedactual checks)
assistive
• Complex multi-step business scenarios not yet automated
• Third-party integrations with limited test environments
• Devices/browsers outside automated matrixtechnology

Manual testing is NOT required for:

• Regression of previouslyall testedautomated featurestest (automate these)paths
• CRUDFee operationscalculations on(fully standardautomated formsin unit tests)
• Unit-levelInput logicvalidation (covered by input-chaos Playwright project)
• DB compliance checks (fully automated testsin db.test.ts)

---

7. Code Coverage Requirements

Layer	Lines	Branches	Functions	Notes
BusinessAuth logicmodule	≥ {{BIZ_COV}}%100%	≥ {{BIZ_BRANCH}}%100%	≥ {{BIZ_FN}}%100%	Strictly enforced — financial security
Transaction processing	100%	100%	100%	Strictly enforced — financial correctness
API handlers	≥ {{API_COV}}%80%	≥ {{API_BRANCH}}%70%	≥ {{API_FN}}%80%
UtilitiesInput validation	≥ {{UTIL_COV}}%90%	≥ {{UTIL_BRANCH}}%85%	≥ {{UTIL_FN}}%100%	Security-critical
UIDB componentslayer	≥ {{UI_COV}}%90%	—	≥ {{UI_FN}}%90%	RenderCompliance +assertions interactionrequired
Overall minimum	≥ {{TOTAL_COV}}%80%	—	—	CI gate — build fails below

Coverage enforcement: CI pipeline fails if coverage drops below minimum80% overall Coverage report: Published toas {{COV_REPORT_URL}}CI artifact on every PR

---

8. Quality Gates

PR Merge Gate (must pass before merge)

• All unit tests pass (npm run test)
• All integration tests pass
• Coverage ≥ minimum80% thresholds(≥ 100% for auth + transaction paths)
• No HIGH/CRITICAL security findings (SAST/SCA)npm audit)
• No secrets detected (pre-commit hook)
•  TypeScript compiles (npm run type-check)
• Linting passes
•  Type checking passes (ifnpm typedrun language)lint)

Staging Deploy Gate (must pass before staging deploy)

• All PR gates passed
• Build artifact created and signedpushed to Fly.io

Production Deploy Gate (must pass before production deploy)

• All Playwright E2E tests pass on staging (user-flows, full-flows, input-chaos)
• Performance baseline not degraded > {{PERF_REGRESSION}}%10% (api-benchmarks.test.ts)
• Manual QAUAT sign-off from Alem Bašić (if sprint includes new features)CEO)
• ManualSecurity approvalaudit inscore CI≥ pipeline80/100

---

9. Responsibility Matrix

Test Type	Writes Tests	Reviews Tests	Maintains Tests	Signs Off
Unit tests	DeveloperBuilder agent	PRValidator revieweragent	DeveloperBuilder agent	TechJohn lead(AI Director)
Integration tests	DeveloperBuilder agent	QAValidator engineeragent	DeveloperBuilder agent	TechJohn lead(AI Director)
E2E tests	QABuilder + Developeragent	TechValidator leadagent	QABuilder engineeragent	QAJohn lead(AI Director)
Performance tests	DevOpsBuilder + Developeragent	TechValidator leadagent	DevOpsBuilder agent	EngJohn manager(AI Director)
Security tests	DevOps (automated)	SecurityBuilder agent	DevOpsValidator agent	SecurityBuilder leadagent	John (AI Director)
DB compliance tests (db.test.ts)	Builder agent	Validator agent	Builder agent	John (AI Director)
UAT (manual)	N/A	John	N/A	Alem Bašić (CEO)

---

10. Test Reporting & Metrics

Metric	Target	Reporting
Test pass rate	≥ 99%100% (unit)unit/integration), ≥ 95% (E2E)	CI dashboard
Flaky test rate	< {{FLAKY_RATE}}%2%	WeeklyPer-run reportanalysis
Test execution time (unit+integration)	< {{TOTAL_TEST_TIME}}3 minminutes (full suite)total	CI dashboard
Coverage trend	Stable or improving	PR comments
TestsDB addedcompliance per sprinttests	≥100% {{TESTS_PER_SPRINT}}pass always	SprintCI metricsdashboard

---

11. Continuous Testing in CI/CD

See CI/CD Pipeline for full pipeline details.

Stage	Tests Run	Blocking
Pre-commit (local)	Unit tests, lintinglinting, type-check	Yes (can be bypassed with --no-verify with justification)
PR open / update	Unit + integration + SAST +(npm SCAaudit)	Yes — blocks merge
Staging deploy	E2E,Playwright visualE2E regression(all 3 projects)	Yes — blocks production
Production deploy	Smoke tests,tests monitoring(health check+ critical journeys)	Yes — auto-rollback on failure
Scheduled (nightly)	Full E2E suite, performance baselinesuite	No — alerts only

Current test inventory (14 test files):

• Unit: auth.test.ts, validation.test.ts, transactions.test.ts, rates.test.ts
• Integration: api-endpoints.test.ts, db.test.ts, middleware.test.ts
• Performance: api-benchmarks.test.ts
• Regression: regression-suite.test.ts, feature-flags.test.ts, sumsub-integration.test.ts, cards-integration.test.ts
• E2E: user-flows.spec.ts, full-flows.spec.ts, input-chaos.spec.ts

---

Related Documents

• Test Plan
• E2E Test Plan
• Performance Test Plan
• Definition of Done
• CI/CDTesting PipelineGuide
• Test Inventory

---

Approval

Role	Name	Date	Signature
Author	John (AI Director)	2026-02-23	Approved (AI)
ReviewerQA Lead	Validator Agent	2026-02-23	Approved (AI)
ApproverAI Director (John)	John	2026-02-23	Approved
CEO (Alem)	Alem Bašić	TBD