Re: Organiser les tests

Bonjour Thomas,

On 28/03/2022 19:34, Thomas De Contes via Ada-france wrote:
> Bonjour :-)
> 
> 
> J'ai déjà lu à plusieurs endroits que c'est important d'avoir des tests bien faits (je ne me rappelle plus les termes).
> (Par exemple ici mais pas que :
> https://www.ionos.fr/digitalguide/sites-internet/developpement-web/test-unitaire-dans-le-developpement-de-logiciels/ )
> 
> Ça va être particulièrement utile au moment où je vais changer l'implémentation de certaines fonctionnalités déjà existantes, pour vérifier qu'il n'y a pas de perte de fonctionnalité.
> 
> 
> Mon problème est que je n'ai pas appris beaucoup de choses à la fac sur cet aspect du développement.
> 
> Alors je crois que pour bien tester un composant on n'a pas tellement d'autre choix que de l'"examiner sous toutes les coutures", de façon exhaustive.
> 
> Mais je me pose des questions pour l'organisation plus générale.
> Par exemple est-ce qu'il vaut mieux faire une grande quantité de petits exécutables, chacun étant spécialisé, ou vaut-il mieux en faire un seul avec plein de petits paquetages pour chaque composant à tester ?
> Et il y a peut-être d'autres choses à savoir, pour lesquelles je n'ai pas l'idée de poser des questions.
> 

Les tests sont bien souvent négligés par les développeurs.
C'est bien de se poser la question :-)

Il n'y a pas de recette magique car cela dépend du composant à tester, de l'objectif global, de la couverture à obtenir etc.

Pour ma part, que ce soit en Ada, C ou Java, j'essaie de:

- avoir des tests simples sur les opérations d'un paquetage.
   En Ada, j'utilise un paquetage 'Tests' fils du paquetage à tester.
   Cela permet au paquetage fils de voir les types privés et ensuite de tester ces parties.

- avoir des tests spécifique à chaque opération si possible plutôt qu'un "gros" test fourre tout.
   Si un test échoue, cela permet d'identifier le problème et de plus facilement le corriger.
   Plus un test est compliqué, plus cela devient difficile à maintenir et à corriger quand il y a un problème.
   Bien souvent on néglige le fait que les tests doivent être maintenus :-)

- tester les opérations critiques/sensibles où il y a un risque d'erreur dans la logique
   ou l'algorithme

- avoir un seul binaire de test si possible car c'est plus facile à lancer et à maintenir (à mon avis).
   un seul binaire permet d'avoir à la fin un rapport global sur les tests.
   (avec plusieurs binaires il faut ensuite consolider les différentes exécutions)

- utiliser gcov/lcov pour regarder et identifier les zones qui sont peu testées.
   A partir d'une certaine couverture (souvent proche de 90%), il reste les cas difficiles à tester.
   En général, les cas liés aux erreurs sont parfois difficiles à tester et il faut simuler ces erreurs.
   (ex: un fichier qui n'existe plus alors qu'il devrait, plus de place sur le disque, ...)

- rester pragmatique parce que faire de bon tests ça peut devenir vraiment compliqué

Concernant GtkAda, je ne suis pas sur qu'on puisse faire des tests au sens AUnit/Junit/Ahven.
Le test d'interfaces est toujours très spécifique et complexe où il faut faire intervenir
des outils souvent externes type Selenium ou autre (ie, déclencher un click sur tel bouton).

Je te conseille de regarder dans les sources de GtkAda dans 'testgtk'.
C'est plutôt un ensemble de demo plutôt qu'un ensemble de tests mais c'est bien fait.
Le résultat n'est plus "automatique" mais ça peut suffire.

A+,

Stephane

> Avez vous des conseils à me donner pour organiser ça ?
> Ou des trucs à lire, pas trop "touffus" (genre tutoriel) ?
> 
> 
> Pour info, j'en ai fait un quasiment complètement moi-même :
> http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/tests/tki/test_images.adb?view=markup&pathrev=257
> 
> 

_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france