Discussion :

[cdm1024]

Bonjour,

J'aimerai savoir comment doit-on s'y prendre si on veut tester l'inégalité ou la négation par exemple avec boost.

A la page : http://www.boost.org/libs/test/doc/c...ols/reference/

Je ne trouve pas de test pour différent. Je m'explique. Je veux tester

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
A a(1), b(2);
BOOST_CHECK_DIFF(a,b) // <- me reponds true, le test est valide
ou
BOOST_CHECK_NEG(a.is_two()) // <- me reponds true, le test est valide

[JolyLoic]

Je ne trouve pas de test pour différent. Je m'explique. Je veux tester

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
A a(1), b(2);
BOOST_CHECK_DIFF(a,b) // <- me reponds true, le test est valide

Tu peux simplement faire BOOST_CHECK(a!=b);

L'intérêt d'avoir un BOOST_CHECK_EQUAL au lieu d'un simple BOOST_CHECK(a==b) est que si le test échoue, on peut avoir affiché les 2 valeurs afin d'avoir une idée du problème. Si on veux que deux valeurs soient différentes, leur valeur importe généralement peu, et ça ne sert alors pas à grand chose d'afficher leur valeur identique si le test échoue, c'est je pense pourquoi les auteurs n'ont pas voulu ajouter trop de tests.

[cdm1024]

d'accord pour ta réponse.

Mais j'ai un test pour tester l'opérateur !=. Et donc ca donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
A a(1), a(2);
BOOST_CHECK(!(a!=2))

C'est la solution d'après ta réponse. Mais je la trouve pas très esthétique. Enfin, c'est une affaire de goût

[Mat007]

Salut,

Personnellement je suis assez faignant donc je ne teste que ce qui est susceptible de ne pas fonctionner, et c'est très rare que le code d'un opérateur de comparaison soit suffisamment complexe pour que j'estime avoir besoin de le tester.
Cela dit comme j'implémente mes operator!= en général en faisant un return !(*this == rhs) ou bien un return !operator==(rhs) dès qu'ils ne sont pas triviaux, je peux me permettre de toute façon de ne tester que operator==.

Par curiosité à quoi ressemble le code de ton opérateur ? Il est vraiment si compliqué que ça ?

MAT.

[cdm1024]

Bonjour,

Non, il est vrai que le code de mon opérateur est trivial. Mais disons que j'ai tendance à vouloir tout tester pour le principe d'anti-regression. Ce qui prend du temps. Mais comme c'est pour un projet perso que je fais dans mes heures de loisir, c'est pas trop grave.

Je me demande si s'était dans un cadre professionel. Prendre une heure pour écrire des tests par classe. Je sais pas si c'est rentable.

[Mat007]

Prendre une heure pour écrire des tests par classe. Je sais pas si c'est rentable.

Oh si, surtout si les tests sont faits avant le code !
Et puis non seulement avec l'habitude on va de plus en plus vite à les écrire, mais on apprend aussi à ne justement pas perdre du temps à tester ce qui n'a pas vraiment de raison de ne pas fonctionner.

Après je trouve que ça passe beaucoup mieux quand tout le monde dans l'équipe en comprend l'intérêt et accepte de jouer le jeu.
C'est sûr que quelqu'un qui reste à développer "à l'ancienne" va voir tout ça comme une gène et va par moment ralentir toute l'équipe (en faisant un "commit" avec des tests qui échouent et qui plantent le build sur le serveur d'intégration mais aussi en bidouillant à l'arrache les tests pour qu'ils passent quand il fait une modification).

Pour moi le code de test fait partie intégrante du code source et doit être traité en tant que tel : nettoyages, remaniements, simplifications, suppression des duplications, etc..
Et puis je trouve aussi que les tests ça fait partie d'une toute autre philosophie de développement et de manière d'articuler le code (quand on utilise des mock objects).
Au final on remarque vraiment bien la conséquence tests simples => code simple...

Bref, les tests c'est bien !

MAT.