Questions

Le mieux serait une combinaison des trois

QuickCheck : gère les cas limites
JUnit : première implémentation
Monolith: migration entre implémentations

Tests pour vérifier, c’est-à-dire ?

Chercher des bugs/comportement inattendu
Vérifier qu’il répond à ces spécifications =

Objectifs des tests = Quand on réalise un système, les tests permettent de faire des économies, car on retire des bugs, ou pour convaincre le client, pour convaincre un organisme de certification : ça dépend donc du projet.

Tests d’acceptation : Test qui vérifie le comportement global du programme fait par le client

Test de bout-en-bout : C’est toi qui le fais sur ton infra, en théorie pas de différence entre le test d’acceptation et le test de bout en bout. Mais en pratique le dev n’est pas fait sur le serveur de prod donc les tests ont des noms différents

JUnit, intérêt ? JUnit ce n’est pas grand-chose, c’est surtout pratique et ça exécute les tests automatiquement et mieux organisé.

Cas pas pertinent de tests aléatoire :

Est-ce qu’on pourrait faire avec QuickCheck ce qu’on fait avec Monolith ? Oui, car Monolith fait des comparaisons entre 2 implémentations, en se basant sur des propriétés à tester similaire à QuickCheck.

QuickCheck, intérêt ? Approche différente des autres techniques, là, on cherche plus des cas difficiles à trouver via d’autres méthodes. Par introspection, QuickCheck peut générer les tests automatiquement, avec des fonctionnalités en + comme expliciter des cas + probable que d’autre.

La couverture ? C’est l’ensemble des cas testés sur l’ensemble des cas possible.

Monolith : tests dos-à-dos, et permet de faire une QuickCheck sur une API (car QuickCheck le fait sur une structure de donnée)

Fusing : test randomisé malin

Instrumentalisation du code ?

En gros tu regardes l’éxécution du code quand tu lances un tests, et tu cherches des cas de tests qui change le fonctionnement interne du code (branches différentes, etc.) pour tester efficacement et trouver + de bugs.