Un compilateur qui produit du code incorrect est pire qu'un compilateur qui ne produit pas de code du tout. La seule défense est le test à chaque niveau. La Session 022 a fait passer FLIN de 717 à 891 tests en une seule session.
Tests d'intégration de bout en bout : 76 tests couvrant douze catégories (variables, arithmétique, déclarations typées, lambdas, expressions match, listes, entités, flux de contrôle, interpolation de chaînes, opérations booléennes, comparaisons, incrémentation/décrémentation).
Tests de cas limites : 74 tests organisés par étape du compilateur -- 27 pour le lexer (source vide, chaîne non terminée, identifiant très long, unicode), 18 pour le parser (bloc vide, parenthèses non équilibrées, imbrication profonde), 14 pour le runtime (division par zéro, débordement de pile, index hors limites).
Benchmarks de performance : 24 benchmarks mesurant chaque étape. La VM exécute 250 000 opérations arithmétiques par seconde. Le cycle complet source-vers-exécution prend 40 microsecondes.
Fuzzing : trois cibles de fuzz utilisant cargo-fuzz couvrant le lexer, le parser et le compilateur complet. Le fuzzer génère des millions d'entrées par heure, trouvant les cas limites qu'aucun testeur humain ne penserait à écrire.
L'approche en couches -- tests unitaires, tests d'intégration, tests de cas limites, benchmarks et fuzzing -- crée plusieurs filets de sécurité qui se chevauchent. C'est ainsi qu'on construit un compilateur auquel les développeurs font confiance pour leur code de production.
Ceci est la partie 174 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [173] Le format binaire .flinc - [174] Tests, benchmarks et fuzzing (vous êtes ici) - [175] Commentaires de documentation dans FLIN