Le topic de la programmation, string, chaînes, cuir et compagnie

[deathdigger]

Ouais, y'a quelques questions très spécifiques au C# et d'autres "multi-langages". C'est surtout en français que j'ai du mal, j'ai l'impression que les questions et réponses sont mal formulées (c'est peut-être une traduction de test en anglais faite par un non-développeur).

[Vuzi]

Dites les canards programmeur, j'ai un problème de compréhension sur JUnit (Un framework de test pour Java). Enfin pas vraiment un problème de compréhension, mais je vois pas quoi faire avec dans le cas de mon programme.

De tout ce que je regarde sur internet, ça sert à vérifier le comportement de morceau de code dans le programme. Genre logique pour un truc de test. Mais moi j'ai par exemple des classes qui se connectent à des bases de données, ou d'autres qui récupèrent des résultats, ou même d'autre qui font de l'affichage graphique. Et même des classes de chargement de plugin, càd absolument rien que je me vois tester en écrivant une classe appelant ces autres classes (genre automatiquement en comparant avec ce qu'elles devraient renvoyer). En plus ces classes ont généralement leur propre vérificateur d'erreur (Surtout la BDD où au final c'est juste le try/catch du driver mysql qui check qu'on a bien une connexion et qu'on récupère), donc faire quelque chose qui se contente de récupérer une exception qu'on récupère déjà ... ?

En plus de ce que je lis c'est censé être quelque chose qu'on fait en même temps qu'on dev le programme, hors là on va dire qu'il est plus ou moins terminé.


En fait je suis paumé là. J'ai l'impression de voir ce que c'est, mais de ne pas voir comment le mettre en place dans mon programme... Je vous rassure, c'est un projet d'école (Et JUnit est simplement encouragé), mais là ça me gave un brin. Mon groupe à fait le projet sans faire aucun test unitaire (Ou alors les ont viré, mais bon), et là... heu ça me semble plus simple a debug "à la main" qu'autre chose en fait...

[Tramb]

Bah, tu te rends compte comme ça que les tests unitaires ne s'appliquent pas facilement à tout. Ils ne sont pas l'alpha et l'omega du testing.
Ou leur coût de dev croît avec la complexité des systèmes avec lesquels ils interagissent.
Par exemple pour un jeu vidéo, ils ont une portée assez limitée.

[Orhin]

@Vuzi : http://jbehave.org/
Cadeau pour tester les cas d'utilisations qui te semblent critiques.

[Sekigo Le Magnifique]

Je travaille en python. Et je travaille 95% du temps sur du traitement de données (on récupère un machin via protocole truc, puis on le transforme en bidule et on l'envoie dans la BDD chouette. Ce qui se passe après, c'est pas mon problème).
Et quand j'écris des tests, ce qui m'importe, c'est les données récupérés et les transformations qui en découlent. Savoir où je récupère et comment, je m'en bats la race.
Donc, en gros, si j'utilise par exemple sqlalchemy (c'est un ORM) pour une BDD mysql, je peux facilement abstraire le code de récupération en créant une base de donnée sqlite en local qui est rempli ras la gueule de données que je veux tester. C'est aussi l'interêt d'un ORM.
Parfois, je fais encore plus cradingue et je fais une fausse bibliothèque sql qui a des méthodes qui vont absolument pas appeler la base mais envoyer directement les données que je veux. Voir, quand je me lève du pied gauche, je monkey-patch la bibliothèque à la volée (je ne crois pas l'avoir déjà fait pour sqlalchemy ceci-dit, ptet pour les ftps). Mais je ne recommende pas la dernière méthode, parce qu'elle est source de trop de problème.
Et ensuite, je test mes transformations (ce qui m'importe réelement, et en plus, c'est facilement testable).

Le test coverage à 100%, c'est franchement fastidieux et inutile, à mon avis (et les patrons ne te laissent jamais le temps de toute manière). Faut savoir repérer les trucs que tu veux (et dois) *vraiment* tester dans ton code.
Pour du code qui fait que récupérer des données dans une BDD, et les envoyer dans un template tel quel, j'ai franchement du mal à imaginer l'interêt des tests par exemple.

[Vuzi]

@Vuzi : http://jbehave.org/
Cadeau pour tester les cas d'utilisations qui te semblent critiques.

Je vais regarder ça, merci.

---------- Post added at 19h36 ---------- Previous post was at 19h35 ----------

Bha là le programme, si on omet les plugins, se contente de load des informations dans une base MySQL, de les afficher/modifier ou bien sur d'ajouter de nouvelles entrées. Le truc de base. Pour les plugins c'est un peu plus chiant à tester, mais je pense que je pourrais me débrouiller. Je viens déjà de voir qu'ils ne gèrent pas le cas où la base / une des tables n'existe pas, ainsi qu'un problème de fichier de config qui fait que je me connectais à database.url

Après j'ai pas leur base de donnée, donc je vais m'arrêter là Je le sens tellement ce projet annuel...

[Tomaka17]

Ce que tu décris c'est typiquement le genre de cas de figure où tu n'écris pas de tests.

[kpouer]

Les tests junit, je m'en sert occasionnellement pour des petits bouts de code à la portée réduite. Par exemple une fonction de parsing qui extrait des infos avec une regexp, ce genre de choses.
Quand on écrit ce genre de fonction on fait divers tests, ben je les met tous dans un test jUnit, sur le moment ça semble idiot vu qu'ils passent tous. Mais plus tard quand tu dois corriger ta fonction pour tenir compte d'autre chose, c'est bien d'avoir un test déjà là qui va vérifier que ça marche toujours avec les cas précédents, parce que sinon on a vite fait de ne valider que les nouveautés.
Mais c'est vrai que c'est des tests bas niveau, lorsque ça met en jeu des éléments extérieurs comme des bases de données, ou autre, c'est beaucoup plus compliqué.

[rOut]

Peut être que JUnit n'est pas adapté à des tests necessitant un peut de contexte, il n'empêche que le principe des tests unitaire reste applicable partout. Ca ne sert pas uniquement à tester que les cas passants marchent bien, mais également que le programme se comporte comme prévu en cas d'évènement innatendu. Par exemple comment il est censé se comporter si la DB n'est pas accessible. Le contrat d'interface de chaque composant de ton application doit définir de quelle manière les erreurs sont retournées, et les tests unitaires devraient vérifier que c'est bien le cas. On peut aussi imaginer que ça serve à vérifier que des bugs connus ne sont pas reproduits.

Trop souvent, ça nécessite un outillage supplémentaire et une architecture modulaire (pour bouchonner et isoler une partie de l'application facilement, en simulant le reste), qui ne sont jamais développés faute de temps et d'argent. Ca ne veut pas dire pour autant que ça n'est pas faisable.

Dans une boite précédante, on avait un mec dédié à l'écriture de tests unitaires. Il réécrivait toute la logique de l'application dans son coin, en OCaml, pour pouvoir simuler certaines parties, en tester d'autres et vérifier que les résultats collaient avec l'appli codée séparément. Au final, les bugs de logique étaient rapidement découverts (soit dans la logique des tests, soit dans celle de l'application).

Pour un jeu vidéo, pour simuler de manière globale, on pourrait imaginer un mécanisme capable d'injecter une combinaison de touche ou d'actions user et une capture / comparaison des outputs. Ca se fait bien pour les browsers web, c'est certainement extensible.

[Vuzi]

C'est marrant parce-que par exemple pour mon projet d'interpréteur en C (J'avais posé des questions ici à ce sujet), bha j'ai réalisé pas mal de tests unitaires en fait, pour tester un peu tout les cas de fonctionnement des "composants" de base du programme

Bha du coup merci des réponses, je pense que je vais essayer de debugger comme je peux avec ce que j'ai (Sachant que déjà les cas d'erreur les plus visibles ne sont pas forcément géré, ça n'augure rien de bon)..

[Tramb]

Pour un jeu vidéo, pour simuler de manière globale, on pourrait imaginer un mécanisme capable d'injecter une combinaison de touche ou d'actions user et une capture / comparaison des outputs. Ca se fait bien pour les browsers web, c'est certainement extensible.

Le problème c'est qu'au cours du développement, les captures d'input se périment très très vite, au moindre changement de contenu, de logique ou de timing.

[Tomaka17]

Pareil pour tester les UI.
Tu veux rajouter un bouton ? Hé ben faut réécrire tous tes tests.

[Tramb]

En tout cas, tout le monde sera d'accord pour dire que c'est surtout les développeurs de couches TLS/SSL qui devraient faire plus de unit tests, hihi.

[rOut]

Le problème c'est qu'au cours du développement, les captures d'input se périment très très vite, au moindre changement de contenu, de logique ou de timing.

Comme tous les tests unitaires, ça n'empêche pas que c'est ponctuellement applicable.

[GrandFather]

Souvent (mais pas toujours, j'en fais pas une règle), la difficulté à mettre en place des tests unitaires est le révélateur de problèmes de conception de l'appli (granularité, répartition des responsabilités entre les classes, etc.).

C'est pour cela qu'il est fortement conseillé - conseil que personne ou presque n'applique - de rédiger les tests lors de la phase de conception, avant même de commencer l'implémentation.

[Tramb]

Comme tous les tests unitaires, ça n'empêche pas que c'est ponctuellement applicable.

Un petit peu, mais pour l'avoir beaucoup fait sur différents projets, ça ne résoud qu'une infime partie du problème de QA dans la majorité des types de jeux vidéo.

---------- Post added at 08h32 ---------- Previous post was at 08h27 ----------

Souvent (mais pas toujours, j'en fais pas une règle), la difficulté à mettre en place des tests unitaires est le révélateur de problèmes de conception de l'appli (granularité, répartition des responsabilités entre les classes, etc.).

C'est pour cela qu'il est fortement conseillé - conseil que personne ou presque n'applique - de rédiger les tests lors de la phase de conception, avant même de commencer l'implémentation.

Là tu touches du doigt le fait que le testing unitaire est intrusif sur ton design, et que en introduisant certains bouchons, et découpages, tu testes des choses qui ne sont plus vraiment ton appli.
Bref, quand ça s'applique bien, sur du code peu stateful, il ne faut pas hésiter.
Sur du code très très stateful, ça peut valoir le coup mais on n'explorera pas énormément d'états non plus, alors il faut être malin.
Sur un développement très itératif, ça finit par coûter très cher et freine les modifications.

[Orhin]

Souvent (mais pas toujours, j'en fais pas une règle), la difficulté à mettre en place des tests unitaires est le révélateur de problèmes de conception de l'appli (granularité, répartition des responsabilités entre les classes, etc.).

C'est pour cela qu'il est fortement conseillé - conseil que personne ou presque n'applique - de rédiger les tests lors de la phase de conception, avant même de commencer l'implémentation.

J'ai 2-3 potes qui ont fait ça en stage l'année dernière : écrire d'abord les tests puis l'application, mais ça reste en effet minoritaire (car ne convenant pas à toutes les organisations et méthodes de dev').
Perso je préfère les tests comportementaux, qui sont quand même plus souples et plus utilisables sur de grosses appli'.

[messe sans cause]

J'interviens juste pour plussoyer la réponse de Sekigo.

Le principe c'est de ne pas tester ce qui l'est déjà. Par exemple ton driver mysql on s'en fout, il est déjà testé (normalement ), donc bosse avec des données directement, dans un fichier, sqlite ou autre.

Au début je me faisais avoir. Mes tests couvraient essentiellement mon ORM, qui était déjà parfaitement couvert.

Et ouais en java les tests sont un chouilla moins importants que pour le python ou le ruby, mais ils peuvent faire gagner du temps en appliquant quelques principes de TDD.

[Teocali]

J'interviens juste pour plussoyer la réponse de Sekigo.

Le principe c'est de ne pas tester ce qui l'est déjà. Par exemple ton driver mysql on s'en fout, il est déjà testé (normalement ), donc bosse avec des données directement, dans un fichier, sqlite ou autre.

Je plussoie ce point fortement. A noter que DBUnit est tres utile pour ca. Ca permet de mettre ta source de donne dans un etat donne au debut de chaque test, et ce de maniere reproductible. De meme, ca te permet de tester que tes donnees sont bien dans l'etat voulu, mais ca, c'est moins important

[Tomaka17]

Dites, ça s'appelle comment la syntaxe où on écrit par exemple "+ 2 5" à la place de "2 + 5" ? J'ai complètement oublié.

[Tramb]

Prefix ou polish.

[Tomaka17]

Merci

[deathdigger]

Notation polonaise inversée en français.

[Sahnvour]

Lisp

[deathdigger]

Ou "Pourquoi ta TI-80, elle veut pas faire 5*2 ?"

[ducon]

C’était les HP, pas les Ti.

[Møgluglu]

Et c'est de la Polonaise inverse (2 5 +), pas de la Polonaise (+ 2 5).

[newbie06]

Lisp

Tu sais que tu vas nous énerver Tomaka si tu dis qu'il veut faire du LISP hein ?

[Tomaka17]

Ah mais non je ne veux pas faire du Lisp, c'est juste que je vais utiliser ce système pour passer des formules générées par une fonction à une autre fonction sous forme de tableau.
J'aime bien les langages et les librairies faciles à utiliser, et je ne programmerai donc probablement jamais dans ce langage.

[deathdigger]

C’était les HP, pas les Ti.

My bad, faut dire qu'elle n'était pas à moi et qu'elle traine dans un tiroir depuis 15 ans