Objective-C et les tests unitaires

06122008 Dans: Objective-C

On me demandait dans les commentaires du billet précédent ce qu'était exactement les tests unitaires, je vais donc essayer d'expliquer à quoi ils servent et vous proposer quelques ressources pour aller plus loin.

Comme le nom l'indique, il s'agit de tester le comportement d'un unité d'un programme, c'est à dire par exemple une fonction ou une classe. Pour une fonction qui convertit une température de Celsius en Fahrenheit, on va tester que le résultat de la conversion pour différentes valeurs. On testera des valeurs négatives, positives, des lettres, etc. pour s'assurer que le résultat est correct et que les erreurs sont bien traités. Les tests permettent aussi d'éviter les régressions de votre programme, car lors d'une modification de votre code, vous pouvez exécuter les tests et vous assurez que le comportement n'a pas été altéré par vos modifications récents.

Vient ensuite le concept de couverture de code. Il s'agit de connaître le pourcentage des lignes de code du programme qui sont testés par votre jeu de tests unitaires. Par exemple, si votre fonction contient du code conditionnel avec l'instruction if/else, il faut que les différents tests de la fonction fassent intervenir à la fois le code dans le bloc if que dans le bloc else. Plus le pourcentage est élevé plus vous pouvez avoir confiance dans le comportement de votre code.

Pour allez plus loin, n'hésitez pas à lire les ressources suivantes :

J'espère avoir été assez clair, mais n'hésitez pas en cas de besoin à poser vos questions dans les commentaires.

Articles similaires

Partager

4 Réponses à “Objective-C et les tests unitaires”

  1. Pierre
    7 décembre 2008 | 00:54

    J'ai a peu près compris sauf le coup du pourcentage. Comment fais-tu pour l'obtenir? Merci ^^

  2. Renaud Pradenc
    7 décembre 2008 | 16:19

    Pour le pourcentage, c'est assez simple.
    Imagine une fonction qui contiendrait un seul test conditionnel (un seul if/else).
    Si par exemple, ton test unitaire ne teste que le résultat de la fonction quand la condition est vraie, alors la couverture est de 50% (on a exécuté la moitié du code). Elle est de 100% si tu testes également le cas où la condition est fausse.

    L'idéal serait une couverture de 100% pour tous les modules. En fait, c'est impossible à obtenir. Quand on commence à imbriquer des if dans d'autres if, on augmente la complexité du test de manière exponentielle. Alan Turing a démontré qu'un programme de test exhaustif est forcément plus complexe que le programme qu'il teste… Et il faudrait ensuite programmer un programme de test du programme de test.

    Le but est donc d'obtenir un compromis, le taux de couverture dépendant de la criticité du programme.

  3. mouviciel
    8 décembre 2008 | 14:35

    Dans certains métiers, la couverture à 100% est une exigence.

    Mais même cette couverture à 100% n'est pas le Saint Graal. Si un code n'est pas couvert à 100%, je suis certain qu'il n'est pas complètement testé. Mais s'il est couvert à 100%, je ne peux rien garantir.

    Par exemple, si j'ai un if avec une condition complexe, il se peut que j'arrive à trouver une façon de la rendre vraie, une autre de la rendre fausse et mon code est couvert à 100%.

    Pour autant, il se peut qu'il y ait un bug dans la construction même de la condition que mes tests à 100% de couverture n'auront pas révélé.

    Le test est un art complexe...

  4. Fabien Schwob
    9 décembre 2008 | 11:21

    C'est tout particulièrement vrai dans les domaines où les logiciels sont responsable de vies humaines, comme les avions, les ascenseurs, etc.

    Il faudrait que je retrouve l'url d'un article décrivant le fonctionnement du développement à la NASA. Il y a une équipe de développement et une équipe de test et où l'équipe de test passe sont temps à essayer de faire échouer les programmes de la première équipe.

Laisser un commentaire


Sponsors