Ejecutar pruebas unitarias¶
Referencia de comandos y estrategia de prueba para gitrust.
Infraestructura existente¶
Prueba unitaria de óxido¶
cargo test --workspace # Tous les tests
cargo test -p gitrust-core # Un crate spécifique
cargo test -p gitrust-git # Tests Git (tempdir)
Las pruebas unitarias se integran en cada caja a través de #[cfg(test)].
Pruebas de dramaturgo e2e¶
17 especificaciones que cubren: autenticación, administración, repositorios, problemas, etiquetas, equipos, tokens, configuración y navegación.
# Pré-requis (première fois)
npm install
./scripts/e2e-setup-db.sh # Crée la DB gitrust_test
# Lancer les tests
npm run test:e2e # Mode headless
npm run test:e2e:ui # Mode interactif (navigateur visible)
npm run test:e2e:debug # Mode debug
npm run test:e2e:report # Voir le rapport HTML
Configuración: playwright.config.ts (puerto 4001, base de datos gitrust_test, configuración regional fr-FR).
Estructura del directorio¶
tests/
e2e/ # Specs Playwright (TypeScript)
global-setup.ts # Setup : lancer l'app, créer admin
global-teardown.ts # Teardown : arrêter l'app
fixtures.ts # Fixtures Playwright partagées
auth.spec.ts # Tests authentification
admin.spec.ts # Tests administration
issues.spec.ts # Tests issues
...
integration/ # Tests d'intégration Rust (DB réelle) [à créer]
fixtures/ # Fichiers de test (repos, configs) [à créer]
seeds/ # Seeds Rust pour initialiser la DB de test
mod.rs
seed.rs
Pruebas para agregar¶
1. Pruebas funcionales de API REST (integración de Rust)¶
Pruebas con una base de datos PostgreSQL real para verificar los puntos finales de la API.
Ubicación: tests/integration/ o crates/gitrust-web/tests/
Enfoque recomendado: use reqwest + un servidor de prueba:
// tests/integration/api_test.rs
use reqwest::Client;
#[tokio::test]
#[ignore] // Nécessite une DB + serveur running
async fn test_api_login() {
let client = Client::new();
let res = client.post("http://localhost:4001/api/v1/auth/login")
.json(&serde_json::json!({
"login": "admin",
"password": "test_password"
}))
.send()
.await
.unwrap();
assert_eq!(res.status(), 200);
}
Alternativa: axum::test para probar controladores sin un servidor HTTP:
use axum::body::Body;
use axum::http::Request;
use tower::ServiceExt;
#[tokio::test]
async fn test_health_check() {
let app = create_test_app().await; // Build router with test DB
let response = app
.oneshot(Request::builder().uri("/api/hello").body(Body::empty()).unwrap())
.await
.unwrap();
assert_eq!(response.status(), 200);
}
2. Pruebas funcionales de CI¶
| Test | Description | Priorité |
|---|---|---|
| CI detection | Repo avec .gitrust-ci.yml -> Easy, .dagger/ -> Power, rien -> None |
Haute |
| Pipeline CRUD | Créer, lister, mettre à jour, annuler un pipeline | Haute |
| Config CI | Activer/désactiver CI, modifier triggers, vérifier effet | Haute |
| Variables héritage | Team var + repo var -> merge correct | Moyenne |
| Auto-cancel | Nouveau push annule les pipelines en cours | Moyenne |
| Logs streaming | Append logs + lecture paginée | Moyenne |
| Notifications CI | Pipeline échoue -> notification créée | Moyenne |
Para pruebas de CI: simule dagger con un script de shell que simule el éxito/fracaso:
#!/bin/bash
# tests/fixtures/mock-dagger.sh
echo "Step 1: Building..."
echo "Step 2: Testing..."
if [ "$MOCK_FAIL" = "true" ]; then
echo "FAILED" >&2
exit 1
fi
echo "All checks passed"
exit 0
Configure CI_DAGGER_BIN=tests/fixtures/mock-dagger.sh en las pruebas.
3. Pruebas de dramaturgo e2e para agregar¶
Nuevas especificaciones para funciones de CI y notificaciones:
| Spec | Couverture |
|---|---|
ci-pipelines.spec.ts |
Liste pipelines, détail, status badges |
ci-config.spec.ts |
Config CI (enable/disable, triggers, timeout) |
ci-variables.spec.ts |
CRUD variables CI, masquage secrets |
notifications.spec.ts |
Liste notifications, marquer lu, préférences |
api-docs.spec.ts |
Swagger UI accessible, spec chargée |
i18n.spec.ts |
Changement de langue, textes traduits |
docker-smoke.spec.ts |
docker compose up + smoke test |
Ejemplo de especificación de CI:
// tests/e2e/ci-pipelines.spec.ts
import { test, expect } from './fixtures';
test.describe('CI Pipelines', () => {
test('affiche la page CI vide', async ({ authenticatedPage }) => {
await authenticatedPage.goto('/admin/mon-repo/ci');
await expect(authenticatedPage.locator('text=Aucun pipeline')).toBeVisible();
});
test('bouton trigger CI visible pour le maintainer', async ({ authenticatedPage }) => {
await authenticatedPage.goto('/admin/mon-repo/ci');
await expect(authenticatedPage.locator('text=Lancer CI')).toBeVisible();
});
});
4. Configuración de prueba ↔ comportamiento¶
Las pruebas más críticas verifican que cambiar una configuración modifica el comportamiento observable:
| Setting | Action | Vérification |
|---|---|---|
| PAT révoqué | Appel API | 401 immédiatement |
ci_enabled = false |
Push | Pas de pipeline créé |
trigger_on_push = false |
Push | Pas de pipeline |
auto_cancel = true |
2 pushes rapides | 1er pipeline annulé |
email_on_pipeline_failure = false |
Pipeline échoue | Pas d'email, notif in-app ok |
DEFAULT_LOCALE = en |
Charger page | Texte en anglais |
Comandos de prueba¶
# Tests unitaires Rust
cargo test --workspace
# Tests avec filtrage
cargo test -p gitrust-core -- ci_service
cargo test -p gitrust-core -- notification
# Tests e2e Playwright
npm run test:e2e
# Tests e2e spécifiques
npx playwright test tests/e2e/ci-pipelines.spec.ts
npx playwright test --grep "notifications"
# Lint
cargo clippy --workspace -- -D warnings
# Format check
cargo fmt --all -- --check