Vidocq Documentation

Cette page consolide l’état des exécutions du TCK officiel MicroProfile Health 4.0 sur Knock. Knock vise la conformité totale : passer le TCK est un contrat ferme avant toute fusion structurelle.

Synthèse

Métrique Valeur Notes

Spécification testée

MicroProfile Health 4.0

Exécuté contre le fork Vidocq knock-mp-health-api.

Tests exécutés

28

Suite officielle du TCK.

Réussis

28

Conformité à 100 %.

Échoués

0

Aucune interprétation divergente de la spec, aucun test désactivé.

Erreurs / ignorés

0

Aucun crash JVM, aucun Throwable non capturé.

La conformité étant à 100 % sans test désactivé, il n’existe pas de TCK.md listant des exclusions — chaque assertion de la suite est honorée.

Couverture

Domaine État

Contrat HealthCheck et HealthCheckResponse

✅

Qualificateurs de sonde (@Liveness, @Readiness, @Startup)

✅

Endpoints (/health, /health/live, /health/ready, /health/started)

✅

Règle d’agrégation (DOWN si un DOWN, vide = UP)

✅

Gestion des exceptions (repliées en contrôle DOWN)

✅

Forme de la charge JSON (status, checks[], data optionnel)

✅

Correspondance des statuts HTTP (200 UP / 503 DOWN)

✅

SPI HealthCheckResponseProvider

✅

Reproduire localement

Le TCK s’exécute via un script dédié à la racine du dépôt :

cd knock
sdk env

# Test de fumée (KnockTckSmokeTest uniquement)
./run-official-tck-mp-health-4.0.sh

# Suite officielle complète (28 tests)
./run-official-tck-mp-health-4.0.sh all

# Un seul test par nom
./run-official-tck-mp-health-4.0.sh -Dtest=TestName

Le runner peut aussi être invoqué directement via le réacteur :

./mvnw -Ptck -pl knock-tck test                  # smoke
./mvnw -Ptck,tck-official -pl knock-tck test     # suite officielle complète

Le TCK s’exécute sur le classpath (et non le module path), contournement Java Modules délibéré pour Arquillian/ShrinkWrap. Depuis le 2026-07-15, knock-tck est dans le réacteur mais gardé derrière le profil Maven tck (même motif que les runners vidocq-runtime-tck-*) : un build ordinaire ne construit ni ne télécharge le harnais TCK. La contrainte historique ShrinkWrap Maven Resolver 3.3 vs Model 4.1.0, qui maintenait autrefois le runner hors du réacteur, est obsolète depuis la migration Maven 3.9.16 / Model 4.0.0.

Voir aussi