Dire que l'implémentation n'est pas correcte c'est un peu prétentieux. Voici l'implémentation de
Je pense que ce langage à fait ses preuves en termes de robustesse.
Mai oui tu as tout à fait raison je fais l'amalgame, et comme les développeurs livrent des implémentations et pas des algorithmes, c'est pour ça qu'on fait des tests qui prennent en compte le cadre d'utilisation et non pas des preuves de la correctature des algorithmes. CQFD j'ai envie de dire. Et moi non plus je ne sais pas combien de temps ça pourrait prendre de prouver une appli complète, c'est vraiment d'un autre niveau. Ceci dit ça m'intéresse de plus en plus.
ça se tient Moi je disais çà parce que en réalisant l'implémentation on a rapidement une idée des cas à tester auxquels on ne pense pas dès le début. Comme on l'a vu, les test c'est du code et à ce titre ça se refactore et ça se maintient. On fait des tests, on implémente et là on pense à d'autres cas et on rajoute des tests. Ou bien ça plante et on teste les cas qui buggent|boguent|bug (^^) Et perso j'adore me créer des problèmes et les résoudre en algo ou en jouant à un JV, et en être fier quand c'était chaud
Mais bon ok pour le binôme. Celui qui fait que les tests doit quand même se faire iech.
Pour les frameworks je m'engage à lire la doc et à l'utiliser du mieux que je peux. Je me fais pas virer si je me plante. Je dois choisir aussi un framework ou à leur tour les devs sont censé pondre un code qui marche, et testé. Un quote que j'aime bien des créateurs d'Erlang :
Things fails. Prouver des algorithmes triviaux est une perte de temps, je crois qu'il est bon de se concentrer sur les tests des parties les plus sensibles en priorité. Mais prouver théoriquement certains alorithmes, si on en a les compétences et le temps sera toujours une bonne chose. Faudra quand même tester l'implémentation.
Ces fonctions ont des effets de bord, je ne pense pas qu'on puisse prouver la correctitivité des algos inhérents. Je vais demander sur Stack Ov'
length
dans la librairie standard de haskell que j'ai honteusement pompée :length :: [a] -> Int
length [] = 0
length (_:l) = 1 + length l
Je pense que ce langage à fait ses preuves en termes de robustesse.
Mai oui tu as tout à fait raison je fais l'amalgame, et comme les développeurs livrent des implémentations et pas des algorithmes, c'est pour ça qu'on fait des tests qui prennent en compte le cadre d'utilisation et non pas des preuves de la correctature des algorithmes. CQFD j'ai envie de dire. Et moi non plus je ne sais pas combien de temps ça pourrait prendre de prouver une appli complète, c'est vraiment d'un autre niveau. Ceci dit ça m'intéresse de plus en plus.
Citation :Au contraire: je pense qu'implémenter le test ET sa solution est une mauvaise approche. A l'université, et dans certaines entreprises surement (à l'école aussi d'ailleurs), on utilise la programmation en binôme: l'un code les tests, l'autre code la solution. Si tu code tes tests et ta solution, c'est comme si tu te créais des problèmes que tu es ensuite fier de savoir résoudre... Tu n'auras pas couvert tout le champ des problèmes possible et tu vas en rater des tas (un peu dans le même style que le type qui te dit "j'ai une question bête" qui te coule tout un projet).
ça se tient Moi je disais çà parce que en réalisant l'implémentation on a rapidement une idée des cas à tester auxquels on ne pense pas dès le début. Comme on l'a vu, les test c'est du code et à ce titre ça se refactore et ça se maintient. On fait des tests, on implémente et là on pense à d'autres cas et on rajoute des tests. Ou bien ça plante et on teste les cas qui buggent|boguent|bug (^^) Et perso j'adore me créer des problèmes et les résoudre en algo ou en jouant à un JV, et en être fier quand c'était chaud
Mais bon ok pour le binôme. Celui qui fait que les tests doit quand même se faire iech.
Pour les frameworks je m'engage à lire la doc et à l'utiliser du mieux que je peux. Je me fais pas virer si je me plante. Je dois choisir aussi un framework ou à leur tour les devs sont censé pondre un code qui marche, et testé. Un quote que j'aime bien des créateurs d'Erlang :
Citation :“The world is concurrent. Things in the world don’t share data. Things communicate with messages. Things fail.”
- Joe Armstrong
Things fails. Prouver des algorithmes triviaux est une perte de temps, je crois qu'il est bon de se concentrer sur les tests des parties les plus sensibles en priorité. Mais prouver théoriquement certains alorithmes, si on en a les compétences et le temps sera toujours une bonne chose. Faudra quand même tester l'implémentation.
(26-08-2013, 10:42 PM)Sephi-Chan a écrit : Une méthode Javascript qui ajoute un élément dans le DOM.
Une méthode (PHP ou autre) qui retourne tous les joueurs paginés par 10.
Idem pour celles dont j'ai donné mes specs plus haut.
Ces fonctions ont des effets de bord, je ne pense pas qu'on puisse prouver la correctitivité des algos inhérents. Je vais demander sur Stack Ov'