# lambda-moneyhub integration tests

### Requirements
- Active MFA session (`awsume`)
- Python 3.14+
- Run all commands from `lambda-moneyhub/tests/`

### Setup (env)
Only needed for the non-Docker QA targets (`make test_integration`, `make test_all_integration`):
```
python -m venv env && source env/bin/activate
pip install --extra-index-url https://pypi.theorchard.io/pypi/ ".[dev]"
```

### Run tests against QA

| Command | Description | Needs virtual environment? |
|---|---|---|
| `make test_integration function='<name>'` | One lambda against QA | Yes |
| `make test_all_integration` | All lambdas in parallel against QA | Yes |
| `make docker_test_integration function='<name>'` | One lambda in Docker (CI parity) | No |
| `make docker_test_integration` | All lambdas in Docker (CI parity) | No |

### Run tests against the RIE

The AWS Lambda RIE (Runtime Interface Emulator) is a lightweight local proxy that emulates the Lambda Runtime API, letting you run and test containerized lambda functions locally without deploying to AWS. It translates HTTP requests into Lambda invocation events.

RIE tests run against a local RIE container connected to **QA** resources.

**First-time setup** — copy `.env.shadow` to `.env` and fill in your credentials:
```
cp .env.shadow .env
```
On Apple Silicon, Colima must use the VZ virtualisation framework with Rosetta 2 (QEMU causes crashes in the RIE):
```
colima start --vm-type vz --vz-rosetta
```

#### Option A — one-shot (CI parity)
Builds lambda and test images, runs tests, tears down. Identical to what CI runs.
```
make ecr_login                           # optional (once per session)
make docker_rie_test function='<name>'   # build, test, teardown
```

#### Option B — interactive (for debugging)
Keeps the lambda running so you can re-run tests without rebuilding.
```
make ecr_login                               # optional (once per session)
make up_rie_lambda function='<name>'         # 1. build & start lambda in background
make test_rie_lambda function='<name>'       # 2. run tests in docker — re-run as needed
make down_rie_lambda function='<name>'       # 3. teardown when done
```
Changes to test files under `integration/` and `src/` are reflected immediately — no rebuild needed between re-runs. Both lambdas can be run in parallel (each uses an isolated Docker project and a unique host port).

You can also run step 2 directly from a virtual environment (skipping the test Docker container) — each lambda exposes a fixed host port (`custom_reports` → 9001, `generate_attachments` → 9002):
```
LAMBDA_ENDPOINT_URL=http://localhost:<port> pytest integration/<name>/test*.py -o "addopts=" --log-cli-level=INFO
```

### Run RIE tests on a PR branch

RIE tests do not run automatically on every PR. Trigger them on demand by one of:

| Method | How |
| --- | --- |
| PR comment | Post `run rie tests` (auto-detect changed lambdas; runs all if no lambdas changed) or `run rie tests <function>` (specific lambda) |
| Jenkins parameter | Set `RUN_RIE_TESTS=true` when triggering the build manually |

To scope to a specific lambda when triggering manually via Jenkins, set `LAMBDA_FUNCTION_NAME`.

### Before committing

Requires an activated virtual environment with all dependencies installed:
```
make format  # auto-fix formatting
make lint    # ruff + mypy checks
```

### Adding a new lambda
Add the function name to `INTEGRATION_TESTS_FUNCTIONS` in the root `Jenkinsfile`:
```groovy
@groovy.transform.Field List<String> INTEGRATION_TESTS_FUNCTIONS = ['custom_reports', 'generate_attachments', 'your_new_function']
```

### CI behaviour

**PR builds** — integration tests run on demand only (see [Run RIE tests on a PR branch](#run-rie-tests-on-a-pr-branch) above); they do not run automatically on every PR.

**Master builds** — integration tests run on every build following this logic:
- Lambda code changed → only affected lambdas with integration tests are run; lambdas without integration tests are skipped
- No lambda code changed (e.g. only test files, Jenkinsfile changed) → all integration tests run