Re: Organiser les tests

Le 28 mars 2022 à 23:29, Stephane Carrez via Ada-france a écrit :

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

:-)
(J'ai été repêcher les tests fait par le 1er auteur, parce que le suivant n'a pas jugé utile de les conserver !)

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

On va dire vite fait que l'objectif global c'est de faire "ce qui est à portée de main".
Disons que si je ne faisais pas ce qui est facilement accessible, je considérerais que "je n'ai pas fait ma part".


> 
> 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.

En lisant ca :
https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-154/tests-unitaires-avec-check-gcov-et-lcov
je comprend que tu fais des tests de type boîte blanche.

Alors je visualise très bien ce que sont les tests de type boîte noire :
On a des entrées et des sorties, et il faut tester potentiellement toutes les possibilités, pour vérifier que les sorties sont bien ce qu'on attend.

Mais je n'arrive pas à visualiser le concept des tests de type boîte blanche :
Je vois que tu fais un paquetage enfant pour accéder à la partie privée de la spec (je crois que le corps reste inaccessible).
Mais ensuite, quel est le but ? Qu'est-ce qui doit être testé ?

> 
> - avoir des tests spécifique à chaque opération si possible plutôt qu'un "gros" test fourre tout.

Si tu parles de tout mettre dans la même unité, c'est évident !
Il y a un Test_Everything qui ressemble à ça, mais je vais le décortiquer, supprimer les doublons avec les autres, etc ...

>  Bien souvent on néglige le fait que les tests doivent être maintenus :-)

:-D
(Pour ma part j'ai commencé à mettre un minimum de commentaires - juste pour délimiter des grandes parties. Je crois avoir compris l'importance des commentaires, mais d'une façon générale c'est pas mon point fort.)

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

Ok. Bon ben, j'espère que je saurai correctement les identifier ...

> 
> - avoir un seul binaire de test si possible car c'est plus facile à lancer et à maintenir (à mon avis).

Ok.
Je ne me vois pas (pour l'instant) faire une interface sophistiquée dans le style de testgtk, donnant la possibilité au testeur d'aller où il veut.
Mais pour commencer, je peux toujours faire une procédure qui appelle simplement toutes les autres, et ne pas demander au constructeur de transformer les autres en exécutables.
C'est vrai que par rapport à tout lancer depuis le Makefile, j'ai déjà l'avantage de maitriser l'ordre d'exécution.
J'aurai l'inconvenient de ne pas pouvoir choisir de n'en exécuter qu'un seul.


>  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)

Là tu me parles de quelque chose que je ne connais pas.


> 
> - utiliser gcov/lcov pour regarder et identifier les zones qui sont peu testées.

Il me semble qu'en Ada, c'est GNATtest et GNATcoverage qui font l'équivalent. Malheureusement ils sont payants ...

>  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).

Pour l'instant, je vais volontairement ne pas traiter les cas difficiles (certains cas limites, besoin d'outils externes, ...).
Simplement parce que c'est le bon sens de ne pas mettre ça en haut des priorités.
Ce qui est facile à faire, je vais essayer de le faire bien. :-)

> 
> 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.

Je pense faire quelque chose qui ressemble à ça pour tester tous les composants graphiques, mais de façon exhaustive, quand même
(testgtk je ne sais pas, mais ceux que j'ai récupérés ne sont pas exhaustifs).

Pour ceux qui traitent les fichiers je n'ai pas encore d'idée,
mais pour ceux qui ne font que du calcul interne, il me semble que les assertions (genre post-condition) devraient suffire, ça ne devrais pas être nécessaire de faire des tests séparés,
qu'en penses-tu ?

> Le résultat n'est plus "automatique"

Peux tu préciser stp ?
Est-ce que ça a été automatique à un moment, ou est-ce que tu compares avec l'utilisation d'outils comme Selenium ?


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

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