Reprise du message précédent :
Non c'est juste que je viens de commencer un bouquin sur JUnit et comme toujours ça commence avec les bons principes TDD&co et je me suis dit "C'est étrange que personne n'y ait pensé".  
Pas le prendre mal hein

Disons qu'un unitest sur quelque chose qui a des effets de bords (ici l'écriture à l'écran), c'est pas terrible, sauf logiciel de comparaison de capture écran...

Notes qu'en langage D, tu as directement dans le langage la notion de bloc unittest {...}  le plus souvent rempli avec des asserts et testé à la compilation avec l'option -unittest

A+,

Bah c'est pas compliqué de faire un assert_equal fonction_5_etoiles_inc, "*
**
***
****
*****"
 

Sauf que la tu supposes que ton code envoie une seule grande chaine en sortie, et non 10 chaines successives. ça doit en général être faisable, mais dans certains cas, en sed par exemple, ou en forth, ça doit considérablement compliquer le programme, et ça, c'est pas le but d'un unittest.
A+,

Point taken.
Mais dans ces langages là t'as pas moyen de définir le STD output? De manière à lui faire rediriger tous ses flux vers un output contrôlé par ton test et ensuite lancer l'assert?

Dans le cas du Forth, le programme donné utilise un EMIT, et ça, c'est censé n'aller que sur la console système.
(la définition de la console (et donc sa redirection) est explicitement en dehors de ce qui est couvert par le standard ANSI Forth.)
A+,

Pour ce genre de chose, un test en dehors du programme est possible (au moins sur les plateformes permettant de rediriger la sortie standard).

C'est pour ça que j'ai parlé de logiciel de comparaison de capture écran.
C'était entre autres ce qu'utilisait, de manière automatisée, mes équipes de tests, pour vérifier la non régression des logiciels que mon équipe développait (des éditeurs de documents industriels), pour vérifier au pixel près, l'identité du rendering d'un même document, entre la version de test et la version étalon.
A+,

Ouais, puis c'est plus élégant que de se contenter de comparer les chaîne de caractères envoyées sur la sortie standard.

Au départ, on parlait de tests unitaires réalisés directement dans le langage et non pas via des moyens externes.
Et j'ai alors indiqué qu'il y a des cas ou ce n'est pas faisable, soit parce que le test implique la modification du code de la procédure à tester, ce que ne doit pas faire un test, soit parce que la procédure à tester a des effets de bord, comme l'écriture sur console, qu'il n'est pas possible de rediriger depuis le langage.
Bien sur que si tu développes pour un programme dont les i/o sont des flux de caractères, tu peux tester de manière externe les chaines de caractère. Mais ce n'est pas toujours le cas, si tu développes pour un GUI.
Par exemple quand tu développes un éditeur WYSIWYG, qui gère complètement l'affichage, le kerning, l'interlignage, l'hyphénation etc etc, tu n'as pas 50 moyen de tester la non régression sinon l'emploi de logiciels de comparaison de capture écran. Je présentais juste ce cas, peut être pas courant pour une majorité de devs, mais qui a été mon pain quotidien pendant des années (et pour la non régression pour les impression pdf ou pcl, c'est encore plus joyeux..., surtout si le point fort de ton logiciel est l'assurance d'une impression identique, quelque soit la plate forme sur lequel le logiciel tourne)
A+,

Alors toi tu as le droit de troller, et moi non ? C4EST 9A ??? §§§ /FOU/

C'est vrai qu'on peut s'attendre à tout de la part de quelqu'un dont la signature montre qu'il ne fait pas la distinction entre un pingouin et un manchot
A+,

Pingouin :
 
Manchot :

C'est pas parce qu'en anglais, on ne fait pas la différence entre pingouin et manchot, que c'est pareil en français ( http://fr.wikipedia.org/wiki/Manchot VS  http://fr.wikipedia.org/wiki/Pingouin )

C'est pas parce qu'on a toujours fait n'importe quoi qu'il faut continuer.

Ca dérive

Mais on la fait aussi en anglais, quand on a une certaine éducation:
Auk = pingouin (et bestioles apparentées)
Penguin = manchot.
A+,