Skip to content

TESTS.md

Latest commit

 

History

History
162 lines (125 loc) · 5.16 KB

TESTS.md

File metadata and controls

162 lines (125 loc) · 5.16 KB

Tests Git Server S3

Cette documentation décrit l'architecture et l'organisation des tests pour le serveur Git S3.

Vue d'ensemble

Nous avons implémenté une stratégie de tests complète qui couvre :

  • Tests unitaires des contrôleurs API
  • Tests d'intégration avec stockage local
  • Tests des cas d'erreur
  • Benchmarks de performance
  • Couverture de code

Types de tests

1. Tests unitaires du Repository Controller

Fichier: internal/api/controller/repo_controller_test.go

# Exécuter uniquement les tests du controller
go test ./internal/api/controller/ -v

Tests couverts:

  • ✅ TestCreateRepoSuccess - Création réussie d'un repository
  • ✅ TestCreateRepoInvalidJSON - Gestion des JSON invalides
  • ✅ TestCreateRepoMissingName - Gestion des noms manquants
  • ✅ TestCreateRepoStorageError - Gestion des erreurs de stockage
  • ✅ TestListReposSuccess - Listage réussi des repositories
  • ✅ TestListReposEmpty - Listage avec liste vide
  • ✅ TestListReposStorageError - Gestion des erreurs de listage
  • ✅ TestRepoControllerIntegration - Test d'intégration complet

Architecture:

  • Utilise MockGitRepositoryStorage pour isoler les tests
  • Mocking complet avec stretchr/testify/mock
  • Tests des réponses HTTP et des codes de statut
  • Vérification des appels aux mocks

2. Tests d'intégration

Fichier: cmd/integration_test.go

# Exécuter les tests d'intégration
go test ./cmd/ -v -run TestLocalStorageIntegration

Tests couverts:

  • ✅ Cycle de vie complet repository (création, listage, vérification)
  • ✅ Endpoints Git (info/refs avec git-upload-pack)
  • ✅ Stockage sur filesystem avec validation
  • ✅ Gestion de repositories multiples
  • ✅ Tests des routes API complètes

Architecture:

  • Utilise un répertoire temporaire pour les tests
  • Stockage local pour éviter les dépendances S3
  • Tests end-to-end avec serveur HTTP complet
  • Validation du filesystem et des structures Git

3. Tests des cas d'erreur

Fichier: cmd/integration_test.go (fonction TestErrorCases)

# Exécuter les tests d'erreur
go test ./cmd/ -v -run TestErrorCases

Tests couverts:

  • ✅ JSON malformé
  • ✅ Repositories dupliqués
  • ✅ Accès à repositories inexistants
  • ✅ Gestion des codes d'erreur HTTP

4. Benchmarks de performance

Fichier: cmd/integration_test.go (fonction BenchmarkAPIEndpoints)

# Exécuter les benchmarks
go test ./cmd/ -bench=. -benchmem -v

Métriques:

  • ListRepositories: ~3.9ms/opération
  • CreateRepository: ~1.1ms/opération
  • Mesure de l'allocation mémoire

Organisation des mocks

MockGitRepositoryStorage

Interface complète mockée pour storage.GitRepositoryStorage:

  • GetStorer(repoPath string) (storer.Storer, error)
  • CreateRepository(repoPath string) error
  • RepositoryExists(repoPath string) bool
  • DeleteRepository(repoPath string) error
  • ListRepositories() ([]string, error)
  • Configure() error

Commandes Make disponibles

# Tests unitaires uniquement les contrôleurs
make test-unit

# Tests avec couverture
make test-coverage

# Benchmarks
go test ./cmd/ -bench=. -benchmem -v

# Nos tests spécifiques (qui passent tous)
go test ./internal/api/controller/ -v         # Tests controller
go test ./cmd/ -v -run TestLocalStorageIntegration  # Tests intégration  
go test ./cmd/ -v -run TestErrorCases         # Tests erreurs

Couverture de code

Contrôleurs: 16.8% de couverture

  • Tous les endpoints principaux testés
  • Gestion d'erreurs couverte
  • Codes de réponse HTTP validés

Fonctions communes: Tests existants mais avec des échecs sur la logique de normalisation des chemins

Stratégie de mock S3

Problème initial:

  • Les tests S3 nécessitaient des vraies connexions ou des mocks complexes
  • Le client awss3.Client est difficile à mocker directement

Solution adoptée:

  • Tests d'intégration avec stockage local pour éviter S3
  • Isolation des tests de logique métier des dépendances externes
  • Mocks uniquement pour les interfaces métier (GitRepositoryStorage)

Bonnes pratiques appliquées

  1. Isolation: Chaque test utilise des répertoires temporaires
  2. Nettoyage: Suppression automatique des fichiers temporaires
  3. Timeouts: Tous les tests ont des timeouts de sécurité
  4. Assertions: Utilisation de testify/assert et testify/require
  5. Couverture: Tests de tous les chemins d'exécution principaux
  6. Performance: Benchmarks pour surveiller les performances
  7. Documentation: Tests auto-documentés avec noms explicites

Prochaines étapes possibles

  1. Tests S3 réels: Avec testcontainers et MinIO
  2. Tests du Git Controller: Mocking des opérations Git
  3. Tests de charge: Avec plus de repositories
  4. Tests de concurrence: Accès simultané
  5. Tests de sécurité: Validation des inputs
  6. CI/CD: Intégration dans pipeline automatisé

Résultats actuels

  • ✅ 24 tests passent sur nos nouvelles implémentations
  • ✅ 0 échecs dans nos tests spécifiques
  • ✅ Architecture testable mise en place
  • ✅ Isolation complète des dépendances
  • ✅ Documentation et organisation claire