L'utilité du test unitaire

[Roworll]

(Roworll, si tu parles de tables type SQL, c'est déjà ce que le moteur de BDD fait: il lit toute la table, en optimisant avec un arbre si besoin, jusqu'à temps de trouver l'emplacement de la clef et si elle existe déjà, il remonte l'erreur. Faut pas considérer qu'une fonction "prouvée" doit absolument tout vérifier par elle-même: elle peut très bien s'appuyer sur d'autres fonctions prouvées).

J'ai parlé de "crétinerie sans nom" dans mon exemple sur le SQL
Je m'autocite : "lire le contenu d'une table pour vérifier que la valeur de clé unique qu'on va insérer n'existe pas."

La crétinerie en question étant de faire manuellement un SELECT sur la table pour savoir si la clef y est déjà avant d'éventuellement faire un INSERT. Comme tu l'expliques lors de l'INSERT, SQL va justement faire cette opération.
Donc, vérifier avant d'insérer est idiot, c'est juste une perte de temps et de puissance mue par la volonté de faire un code bullet-proof.
Gérer l'erreur à la manière "let it crash" est dans ce cas bien plus naturel, économe et tout aussi efficace.