# Playwright — a critical payment flow test
# tests/test_payment.py

import re
import pytest
from playwright.sync_api import Page, expect

@pytest.fixture
def app_url():
    return "https://the-internet.herokuapp.com/login"

def test_checkout_total_is_correct(page: Page, app_url: str):
    """
    Critical: the total on the confirmation screen
    must match the sum of items + tax.
    """
    page.goto(app_url)
    page.get_by_label("Username").fill("tomsmith")
    page.get_by_label("Password").fill("SuperSecretPassword!")
    page.get_by_role("button", name="Login").click()

    # Add items — mock cart flow
    page.goto("/cart/add?sku=BOOK-001")
    page.goto("/cart/add?sku=BOOK-002")

    page.goto("/checkout")
    subtotal = page.get_by_test_id("subtotal").inner_text()
    tax      = page.get_by_test_id("tax").inner_text()
    total    = page.get_by_test_id("total").inner_text()

    # fintech-specific: always verify math, never trust UI alone
    def parse(s): return float(s.replace("₹", "").replace(",", ""))

    assert parse(total) == pytest.approx(
        parse(subtotal) + parse(tax), abs=0.01
    ), f"Total mismatch: {total} != {subtotal} + {tax}"

# Pytest + requests — API testing for payment settlement
# Fintech APIs must be verified across idempotency,
# error codes, and edge cases.

import pytest
import requests

BASE = "https://sandbox.example.com"

@pytest.fixture
def auth_headers():
    r = requests.post(f"{BASE}/auth/token",
        json={"client_id": "test", "client_secret": "test"})
    return {"Authorization": f"Bearer {r.json()['access_token']}"}

def test_payment_idempotency(auth_headers):
    """
    Idempotency keys must return the same response
    when the same request is retried.
    """
    payload = {
        "amount": 100_00,
        "currency": "INR",
        "idempotency_key": "test-idem-001",
    }

    r1 = requests.post(f"{BASE}/payments", json=payload, headers=auth_headers)
    r2 = requests.post(f"{BASE}/payments", json=payload, headers=auth_headers)

    assert r1.status_code == 201
    assert r2.status_code == 200   # same payment returned
    assert r1.json()["id"] == r2.json()["id"]

def test_payment_rejects_negative_amount(auth_headers):
    r = requests.post(f"{BASE}/payments",
        json={"amount": -100, "currency": "INR", "idempotency_key": "neg-01"},
        headers=auth_headers)
    assert r.status_code == 400
    assert "amount" in r.json()["error"]

# Ledger reconciliation — a fintech QA-specific test
# Verify that the sum of all credits equals the sum of all debits.

import pytest
import requests

BASE = "https://sandbox.example.com"

def test_ledger_balances(auth_headers):
    """
    Every fintech ledger must always balance:
    sum(credits) == sum(debits) per account per day.
    This is a daily QA check in most regulated fintechs.
    """
    r = requests.get(f"{BASE}/ledger/entries?date=2026-08-28",
                     headers=auth_headers)
    entries = r.json()["entries"]

    by_account = {}
    for e in entries:
        acc = e["account_id"]
        by_account.setdefault(acc, {"credit": 0, "debit": 0})
        if e["type"] == "credit":
            by_account[acc]["credit"] += e["amount"]
        else:
            by_account[acc]["debit"] += e["amount"]

    for acc, sums in by_account.items():
        assert sums["credit"] == sums["debit"], (
            f"Unbalanced account {acc}: "
            f"credit={sums['credit']} debit={sums['debit']}"
        )

# This kind of test only exists in fintech QA.
# It's what "QA in fintech is different" actually looks like.

# GitHub Actions — QA pipeline for a payments service
# Every PR must pass unit + integration + E2E tests
# before merge. Fintech teams do not ship without this.

name: QA

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install deps
        run: |
          pip install -r requirements.txt
          playwright install --with-deps

      - name: Unit tests
        run: pytest tests/unit -q

      - name: Integration tests
        run: pytest tests/integration -q

      - name: E2E tests
        run: pytest tests/e2e --tracing on

      - name: Upload traces on failure
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: traces
          path: test-results/

# In fintech, a broken payment flow = direct revenue loss.
# The QA pipeline is a business control, not a nice-to-have.

// k6 load test — salary-day traffic
// Fintech apps see 10-20x normal load on salary days
// and festival sales. QA must model this.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m',  target: 100 },   // warm-up
    { duration: '3m',  target: 1000 },  // salary-day peak
    { duration: '2m',  target: 1000 },  // steady state
    { duration: '1m',  target: 0 },     // cool-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<400'],   // 95% under 400ms
    http_req_failed:   ['rate<0.005'],  // < 0.5% failures
  },
};

const BASE = 'https://staging.example.com';

export default function () {
  const res = http.get(`${BASE}/api/account/balance`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
  });

  check(res, {
    'status is 200':         (r) => r.status === 200,
    'response under 400ms':  (r) => r.timings.duration < 400,
    'json body present':     (r) => !!r.json('balance'),
  });

  sleep(1);
}

// Reading the results:
// - p95 latency under 400ms → healthy
// - failure rate < 0.5%     → safe to ship
// - anything worse → block release, investigate

Portfolio project — end-to-end payments test suite
(one project that shows fintech-relevant QA skills)

1. Target app
   - Pick a public payments-style demo
     (e.g., saucedemo.com, or a mock banking API)

2. Manual test design
   - 30 test cases covering onboarding, payments,
     refunds, and edge cases
   - Include a bug report with severity
     and financial impact notes

3. Automation
   - Playwright suite for critical flows
   - Pytest API tests for payment endpoints
   - Idempotency and retry scenarios covered
   - All tests run inside GitHub Actions

4. Documentation
   - README with test strategy
   - Screenshot of the CI test run
   - Notes on how the suite prevents real bugs

This project alone can carry a 30-minute interview
on fintech QA roles.

6-month roadmap into fintech QA roles:

Months 1-2:
- Manual test design + SQL fundamentals
- Write 30 well-structured test cases
- Learn payments basics (UPI, cards, refunds)

Months 3-4:
- Playwright automation + Pytest
- API testing with Postman + requests
- Write idempotency and ledger tests

Month 5:
- CI/CD with GitHub Actions
- Read PCI-DSS and RBI testing expectations
- Practice compliance evidence writing

Month 6:
- Interview prep: domain questions + SQL + automation
- Polish portfolio project
- Apply to fintech QA roles

Cities hiring most in India:
Bengaluru, Mumbai, Gurugram, Hyderabad, Pune.