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+,

Salut tout le monde,
je remonte ce sujet au lieu d'en ouvrir un autre car je pense pas que ma question le nécessite, d'autant qu'elle porte sur ce triangle fait avec des étoiles en C.
 
J'étudie le C avec le livre "Le C en 20h" mais je bloque sur cet exercice... J'ai la solution mais j'aimerai la comprendre.
 
Donc la partie principale de mon problème c'est ici :
 

 
Pourquoi j se base sur i ? (j <= i)
De plus, vu que j s'incrémente à chaque boucle, quand j vaudra 2 il y aura donc 2 printf("*" ) qui se feront, et ainsi de suite ?
 
Merci d'avance pour vos réponses !
(j'étais membre avant et les réponses étaient super donc j'espère retrouver la même chose   )

Première ligne une étoile
Deuxième deux étoiles et ainsi de suite.
 
Autant d'étoile que le numéro de ligne ce qui donne ça:
 

Et c'est juste ce que j'ai écris en commentaire sur le code ? i = ligne, j = étoiles ?
Du coup, pour les problèmes de ce style, où il faut écrire sur chaque lignes, on passe par cette réflexion de double boucle ?

Pour comprendre ce genre de problème je pense que la plupart des gens normaux ont la même approche, au moins au début : tu déroules les boucles comme si tu étais l'ordinateur qui exécute le programme.  
1: i=0,j=0. une étoile
2: i=0,j=1 (je sors de la boucle j et je passe à la ligne)
3: i=1, j=0. une étoile
4. i=1, j=1. une étoile
etc.
 
Tu ne t'arrêtes que lorsque tu es certain d'avoir compris ce que fait le programme (en général avant la fin, mais si tu préfères faire les 5 ligne fais les).

C'est là où l'algorithmique prend tout son sens finalement.
On veut aller (trop) vite des fois, coder, coder, coder... qu'on oublie de comprendre avant. Enfin, en ce qui me concerne.
 
Je vais prendre le temps de la réflexion en me mettant à la place de l'ordinateur comme tu dis, c'est une bonne façon.
Merci pour l'explication, je vais la mettre en pratique !

Faire du pas à pas avec un debugger peut t'aider pour cette étape.

merci pour le up qui m'a fait découvrir ce thread

En haskell après mon premier mini cours
 

on pourrais plutot faire une monade ?