veza/veza-backend-api/internal/testutils
senke 376d9adc44 ci: retire legacy backend-ci.yml, centralize Docker probe in SkipIfNoIntegration
Two changes in one commit because they address the same root cause: the
Forgejo self-hosted runner doesn't expose a Docker socket, and the legacy
backend-ci.yml workflow both required Docker for its integration tests
AND enforced a 75% coverage gate that the codebase has never met (actual
~33%). The consolidated Veza CI workflow (ci.yml) already covers the
same Go build / test / govulncheck surface and is now green — there's
no reason to keep the legacy duplicate red in parallel.

1. .github/workflows/backend-ci.yml → backend-ci.yml.disabled

   Renamed, not deleted. Reactivation path:
     - Raise real coverage closer to 75%, OR lower the threshold in the
       workflow file to a realistic value (30–40%)
     - Provide Docker socket access on the runner OR gate the
       integration job on a docker-in-docker service
     - `git mv` it back to .yml

   This finishes the CI consolidation that started in 2c6217554
   ("ci: consolidate rust-ci + stream-ci into ci.yml Rust job").
   backend-ci.yml was the last un-consolidated workflow and its two
   failure modes (coverage gate + missing Docker) made it permanently
   red without measuring anything the consolidated ci.yml doesn't
   already check.

2. testutils.SkipIfNoIntegration: add a runtime Docker probe

   Before: only honored `-short` and VEZA_SKIP_INTEGRATION=1. Tests
   calling GetTestRedisClient / GetTestContainerDB on a host without
   Docker would get past the skip check and then fail inside
   testcontainers.GenericContainer with "rootless Docker not found".
   This is exactly what happened to the J4 TestCleanRedisKeys_Integration
   on the Forgejo runner (run 105).

   After: added a memoized `dockerAvailable()` helper that probes
   testcontainers.NewDockerProvider() once per test process. If the
   probe fails, all tests calling SkipIfNoIntegration skip cleanly
   instead of panicking. Result: J4 worker test skips on Forgejo,
   still runs (and passes) on any host with Docker.

   The probe is centralized so any existing or future integration test
   that calls SkipIfNoIntegration gets this behavior for free — no need
   to sprinkle inline docker checks.

Verification (local, Docker available):
  go build ./...                                                     OK
  go test ./internal/workers/ -run TestCleanRedisKeys_Integration    PASS (3.26s)
  SkipIfNoIntegration logic audited — no_short / no_env_var path
  still runs the Docker probe, Docker-unavailable path calls t.Skip
  with a clear message.

Expected CI impact:
  - Veza CI / Backend (Go): already green, should stay green
  - Backend API CI: no longer runs (workflow disabled)
  - All other statuses unchanged
2026-04-15 16:12:45 +02:00
..
integration STABILISATION: phase 3–5 – API contract, tests & chat-server hardening 2025-12-06 17:21:59 +01:00
servicemocks stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
benchmark.go adding initial backend API (Go) 2025-12-03 20:29:37 +01:00
db.go v0.9.4 2026-03-05 23:03:43 +01:00
db_cleanup_test.go chore(v0.102): consolidate remaining changes — docs, frontend, backend 2026-02-20 13:02:12 +01:00
db_test.go chore(v0.102): consolidate remaining changes — docs, frontend, backend 2026-02-20 13:02:12 +01:00
db_utils.go adding initial backend API (Go) 2025-12-03 20:29:37 +01:00
fixtures.go stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
fixtures_factory_test.go.disabled adding initial backend API (Go) 2025-12-03 20:29:37 +01:00
fixtures_test.go chore(v0.102): consolidate remaining changes — docs, frontend, backend 2026-02-20 13:02:12 +01:00
golden.go stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
golden_test.go stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
main_test.go test(backend): gate testcontainers tests behind VEZA_SKIP_INTEGRATION 2026-04-14 11:45:19 +02:00
parallel.go stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
parallel_test.go stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
performance.go adding initial backend API (Go) 2025-12-03 20:29:37 +01:00
performance_test.go stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
README.md adding initial backend API (Go) 2025-12-03 20:29:37 +01:00
setup.go test(backend): gate testcontainers tests behind VEZA_SKIP_INTEGRATION 2026-04-14 11:45:19 +02:00
setup_redis.go stabilizing veza-backend-api: phase 1 2025-12-16 11:23:49 -05:00
setup_test_helper.go chore(v0.102): consolidate remaining changes — docs, frontend, backend 2026-02-20 13:02:12 +01:00
skip.go ci: retire legacy backend-ci.yml, centralize Docker probe in SkipIfNoIntegration 2026-04-15 16:12:45 +02:00
table_test.go adding initial backend API (Go) 2025-12-03 20:29:37 +01:00
table_test_test.go adding initial backend API (Go) 2025-12-03 20:29:37 +01:00

Test Utilities Package

Ce package fournit des utilitaires pour faciliter l'écriture de tests dans le projet Veza.

Fonctions disponibles

Gestion de la base de données de test

SetupTestDB() *gorm.DB

Crée une base de données de test en mémoire avec toutes les tables nécessaires. Utilise SQLite en mémoire pour des tests rapides sans dépendance externe.

Exemple d'utilisation:

func TestMyFeature(t *testing.T) {
    db := testutils.SetupTestDB()
    defer testutils.CleanupTestDB(db)
    
    // Votre code de test ici
}

CleanupTestDB(db *gorm.DB) error

Ferme proprement la base de données de test.

ResetTestDB(db *gorm.DB) error

Supprime toutes les données de la base de données de test. Utile pour réinitialiser l'état entre les tests.

GetDBStats(db *gorm.DB) (*sql.DBStats, error)

Retourne les statistiques de la base de données de test.

Fixtures de données

Utilisateurs

  • CreateTestUser(db *gorm.DB) (*models.User, error): Crée un utilisateur de test avec des valeurs par défaut.
  • CreateTestUserWithCustomData(db *gorm.DB, username, email string) (*models.User, error): Crée un utilisateur de test avec des données personnalisées.
  • CreateTestAdmin(db *gorm.DB) (*models.User, error): Crée un utilisateur administrateur de test.
  • CreateMultipleTestUsers(db *gorm.DB, count int) ([]*models.User, error): Crée plusieurs utilisateurs de test.

Tracks

  • CreateTestTrack(db *gorm.DB, creatorID int64) (*models.Track, error): Crée un track de test.
  • CreateTestTrackWithCustomData(db *gorm.DB, creatorID int64, title, artist string) (*models.Track, error): Crée un track de test avec des données personnalisées.
  • CreateMultipleTestTracks(db *gorm.DB, creatorID int64, count int) ([]*models.Track, error): Crée plusieurs tracks de test.

Autres

  • CreateTestPlaylist(db *gorm.DB, userID int64) (*models.Playlist, error): Crée une playlist de test.
  • CreateTestRoom(db *gorm.DB, createdBy int64) (*models.Room, error): Crée une room de test.
  • CreateTestMessage(db *gorm.DB, roomID, userID int64, content string) (*models.Message, error): Crée un message de test.

Exemple complet

package mypackage_test

import (
    "testing"
    "veza-backend-api/internal/testutils"
    "github.com/stretchr/testify/assert"
)

func TestMyFeature(t *testing.T) {
    // Setup
    db := testutils.SetupTestDB()
    defer testutils.CleanupTestDB(db)
    
    // Créer des données de test
    user, err := testutils.CreateTestUser(db)
    assert.NoError(t, err)
    
    track, err := testutils.CreateTestTrack(db, user.ID)
    assert.NoError(t, err)
    
    // Votre test ici
    assert.Equal(t, user.ID, track.CreatorID)
    
    // Cleanup (optionnel si on utilise defer)
    // testutils.ResetTestDB(db)
}

Notes importantes

  • La base de données de test utilise SQLite en mémoire, donc les données sont perdues après la fermeture.
  • Les contraintes de clés étrangères sont respectées.
  • Le modèle Session n'est pas inclus dans les migrations automatiques car il utilise uuid.UUID avec gen_random_uuid() qui n'est pas supporté par SQLite.