Cette page consolide l’état des tests TCK officiels Jakarta Servlet 6.1 exécutés contre Foy. Elle est régénérée à chaque release. La source de vérité au quotidien reste le TCK.md du repo lien:https://codeberg.org/Vidocq/foy/src/branch/main/foy-tck/[foy-tck].

Synthèse

Au dernier run complet du profil tck-official, environ 90 % des tests Jakarta Servlet 6.1 sur les packages api.* passent.

Section spec Total Passés Notes

api.jakarta_servlet.servlet.*

~XX

~XX

✅ Couverture quasi complète. // TODO@user: chiffres exacts depuis le dernier run

api.jakarta_servlet.filter.*

~XX

~XX

api.jakarta_servlet.http.*

~XX

~XX

⚠️ 3 erreurs sur HttpServletRequestTestsgetRequestedSessionId semantics + bug TCK substring

api.jakarta_servlet.dispatchtest

~XX

~XX-18

❌ ~18 erreurs : cross-context dispatch (ServletContext.getContext) non implémenté

api.jakarta_servlet.registration

~XX

~XX-10

❌ 10 erreurs : CommonServlets.jar auto-attaché au WAR pas scanné

api.jakarta_servlet.asynccontext

~XX

~XX-11

⚠️ ~11 erreurs : cas pointus setTimeout / startAsync après dispatch

Les chiffres précis sont dans target/surefire-reports/ après un run --all. Pour le détail historique, consulter git log — foy-tck/ sur la branche main.

Tests volontairement skippés

Test Raison

sc40.addJsp*, sc40.addJspFile*

Foy n’embarque pas de moteur JSP — non supporté, non planifié. Pour des pages dynamiques, utiliser Cassini (REST) ou des Servlets pures.

Tests TLD (tagext.*)

Idem, pas de moteur JSP.

// TODO@user: lister ici les batteries supplémentaires explicitement skippées dans foy-tck/TCK.md

// TODO@user

Tests skippés pour cause d’environnement

Ces tests requièrent un container Jakarta EE complet ou un service externe (JNDI applicatif, JMS, JTA). Ils ne représentent pas un manquement applicatif de Foy.

  • Tests JNDI applicatif (@Resource JDBC) — Foy ne fournit pas de pool de datasources intégré, l’application les injecte via Vauban.

  • // TODO@user: compléter depuis foy-tck/TCK.md

Architecture du runner

foy-tck est un module in-reactor gardé derrière le profil Maven tck (harmonisation TCK, même pattern que les runners vidocq-runtime-tck-*) : un mvn install normal ne télécharge ni n’exécute rien du TCK, et le reactor de release ne voit jamais le module. Invocation via ./run-official-tck-servlet6.1.sh, ou directement ./mvnw -Ptck,tck-official -pl foy-tck test.

Note historique. Le module était exclu du reactor (POM Model 4.0.0 standalone) : ShrinkWrap Maven Resolver 3.3 (dépendance transitive du TCK officiel Jakarta) ne savait pas parser les POMs Model 4.1.0 qu’utilisait alors le workspace (Bad artifact coordinates …​ jar:). Cette contrainte a disparu avec la migration du workspace vers Maven 3.9.16 / Model 4.0.0.

Reproduire localement

Pré-requis

Installer dans le M2 local les artefacts TCK officiels Jakarta Servlet 6.1 (non-publics) :

  • jakarta.tck:servlet-tck-runtime:6.1.0

  • jakarta.tck:servlet-tck-util:6.1.0

  • jakarta.tck:servlet-tck:6.1.0 (pom)

Procédure détaillée dans lien:https://codeberg.org/Vidocq/foy/src/branch/main/foy-tck/README.md[foy-tck/README.md].

Lancer le TCK

cd foy
./run-official-tck-servlet6.1.sh                     # smoke test (rapide)
./run-official-tck-servlet6.1.sh --all               # suite complète (long)
./run-official-tck-servlet6.1.sh -Dtest=ServletTests # une classe précise

Intégration CI

- name: Build foy reactor
  run: cd foy && ./mvnw -ntp install -DskipTests

- name: Run Jakarta Servlet 6.1 TCK
  run: cd foy && ./run-official-tck-servlet6.1.sh --all
  # Pré-requis : cache des artefacts TCK officiels dans ~/.m2

Les rapports Surefire sont dans foy-tck/target/surefire-reports/.