L'avantage de s'obliger à 100% de couverture, c'est que te repenses ton architecture, pour éviter justement tout ces cas, qui n'existent pas. Coder en imaginant le test, peut faire gagner beaucoup de temps.
C'est plus l'exception que la regle. Avoir des appels systemes qui ne font jamais d'erreur, avoir de la memoire infini pour ne jamais faire un echec lors d'une allocation, ne pas avoir de corruption de ses systemes de stockage, ... Il y a toujours des erreurs, faut juste faire en sorte que le systeme se degrade pas trop.
Concernant les piles logiciels, si chaque bout est correctement testé, l'assemblage est (censé) avoir peu de bugs.
Tester le cas qui marche, oui. Tester quand une partie du materiel a chaud, froid, recoit un rayon cosmique, ... ca devient moins probable. Sans compter que le materiel moderne est tres tres fortement asynchrone et multi cpu, ce qui introduit des races conditions que tu vas avoir un mal de fou a voir sur une suite de test unitaire.
Une suite de tests limite les regressions, mais pas les bugs.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par cedric . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
C'est plus l'exception que la regle. Avoir des appels systemes qui ne font jamais d'erreur, avoir de la memoire infini pour ne jamais faire un echec lors d'une allocation, ne pas avoir de corruption de ses systemes de stockage, ... Il y a toujours des erreurs, faut juste faire en sorte que le systeme se degrade pas trop.
Tester le cas qui marche, oui. Tester quand une partie du materiel a chaud, froid, recoit un rayon cosmique, ... ca devient moins probable. Sans compter que le materiel moderne est tres tres fortement asynchrone et multi cpu, ce qui introduit des races conditions que tu vas avoir un mal de fou a voir sur une suite de test unitaire.
Une suite de tests limite les regressions, mais pas les bugs.