Infraestrutura de testes.

[gitnnolabs]

O que esse PR faz?

Corrige e unifica a infraestrutura de testes do markapi, que estava incompleta (sem config.settings.test, dependências de pytest incompletas, CI a ignorar falhas com || true).

Entregas principais:

• config/settings/test.py — settings partilhadas por manage.py test e pytest (PostgreSQL via Compose, Celery eager, cache em memória, sem debug toolbar, LLAMA_ENABLED=False).
• pytest.ini + dependências em requirements/local.txt (pytest-django, pytest-cov, coverage, django-coverage-plugin).
• Smoke test em users/tests.py (valida que CustomUser está configurado).
• CI — job renomeado para tests; remove || true; executa manage.py test e pytest com --rm.
• Makefile — django_test/django_fast usam --settings=config.settings.test; novos alvos pytest, pytest_fast, pytest_cov.
• setup.cfg — paths de cobertura alinhados às apps do projeto.
• Documentação — docs/testing.md e secção Testing do README.md.

Este PR não adiciona testes de negócio das apps editoriais; o objetivo é pipeline reproduzível (Docker + CI) que falha de verdade em regressões de configuração.

Onde a revisão poderia começar?

1. config/settings/test.py
2. pytest.ini e requirements/local.txt
3. .github/workflows/ci.yml
4. Makefile (alvos de teste)
5. users/tests.py

Como este poderia ser testado manualmente?

1. Na raiz do repositório: make build (obrigatório após mudança em requirements/local.txt).

2. make up (ou docker compose -f local.yml up -d postgres redis).

3. make django_migrate

4. make django_test — esperado: Ran 1 test / OK.

5. make pytest — esperado: 1 passed.

6. make pytest_cov — relatório de cobertura no terminal.

7. (Opcional) Simular CI:

   docker compose -f local.yml build
   docker compose -f local.yml run --rm django python manage.py migrate
   docker compose -f local.yml run --rm django python manage.py test --settings=config.settings.test
   docker compose -f local.yml run --rm django pytest
   docker compose -f local.yml down

Guia completo: docs/testing.md.

Algum cenário de contexto que queira dar?

• O projeto herdava referências cookiecutter-django (config.settings.test no mypy, README com pytest/coverage) sem ficheiros nem deps correspondentes.
• O Makefile já usava manage.py test, mas a CI corria só pytest com || true, logo o pipeline nunca falhava.
• Mantém-se PostgreSQL nos testes (não SQLite), por causa de django.contrib.postgres e do stack Wagtail.
• Hoje a suite tem 1 smoke test; stubs vazios continuam em markup_doc, xml_manager e reference para testes futuros.

Screenshots

N/A

Quais são tickets relevantes?

N/A

Referências

• docs/testing.md
• Plano interno: infraestrutura de testes (2026-05-15)

---