Journal Outil de génération de tests unitaires automatiques

• # python est ton amis

  Posté par Yannick Beynet (site web personnel) le 14 juin 2004 à 14:51. Évalué à 1.

  

  Je n'ai eut le temps de creuser, mais je sais qu'il existe pas mal de modules pour faire çà sous python (de modules natifs).

  • [^] # Re: python est ton amis

    Posté par Olivier Grisel (site web personnel) le 14 juin 2004 à 15:25. Évalué à 2.

    

    Oui, pour de la doc, se réferer aux chapitres 13, 14 et 15 de l'excellent Dive into Python :
    http://diveintopython.org/toc/index.html(...)
    
    Mais ca ne fait pas de la "génération de tests unitaires automatiques" puisque seul le programmeur connait vraiment la sémantique du code qu'il écrit. Il est donc le seul à pouvoir définir ce qu'il faut et comment tester. Les outils de tests unitaires simplifient juste l'écriture de ces tests.
    
    Un autre outil bien pratique pour chasser les bugs est la programmation par contrat. C'est pas (encore ?) standard sous python, mais il existe un module simple qui permet de définir facilement des contrats pour des classes et de méthodes dans leur docstring : http://www.wayforward.net/pycontract/(...)

• # Ca dépend de ce que tu veux...

  Posté par gege (site web personnel) le 14 juin 2004 à 15:18. Évalué à 1.

  

  Il existe déjà tous les outils issus de la mouvance de Xtreme programming (http://www.xprogramming.com/software.htm(...)) ils ont une liste assez impressionnante d'outils de TU tous basés + ou - sous l'excelent JUnit pour Java... si ton projet n'a pas des contraintes qualités trop fortes ça peut tout à fait suffire et te faire gagner beaucoups de temps...
  
  Ensuite il y a des outils pro et souvent cher genre ceux de Rational pour l'embarqué, va voir sur leur site, ou dans le domaine des EJB (j'y connais rien), mais on joue plus alors dans la même division...
  
  Enfin, ce qui est important, surtout avec les outils xUnit c'est la méthode que tu appliques par dessus, en effet tu peux faire des tests fonctionels, de haut niveau a la limite des test d'integration qui auront une forte valeur ajoutée pour ton projet, mais tu peux aussi faire des tests idiots qui n'apporteront qu'un simulacre de qualité et de confiance dans ton code... si tu bosses dans un projet un peu conséquent, fait toi (ou repompe) un manuel de régle d'UT, tu le regretteras pas...

• # Pour etre plus precis ...

  Posté par Anonyme le 14 juin 2004 à 15:22. Évalué à 2.

  

  ... j'aimerais qu'il fonctionne de la maniere suivante :
  
  Pour chaque methode de chaque classe on lui fournit les données de test et le code correspondant a l'execution de cette methode. A partir d'un template de code il devra etre capable de generer automatiquement le code du test unitaire, le compiler, l'executer, verifier la validité et calculer la couverture. Est si possible le tout en C++ (a la limite facilement adaptable pour le C++). L'idee est de separer le code du test (generer automatiquement) de ses specifications.

  • [^] # La méthode que j'applique

    Posté par niol (site web personnel) le 14 juin 2004 à 19:09. Évalué à 1.

    

    Sur le projet pour lequel je travaille actuellement, j'utilise CPPUnit (http://ccpunit.sourceforge.net(...) ) que j'ai intégré à automake/autoconf/libtool pour compiler, lancer et vérifier le résultat. La facon de procéder est très bien expliquée dans l'exemple pas à pas (http://cppunit.sourceforge.net/doc/lastest/money_example.html#money(...) )
    
    Pour ce qui est de l'automatisation, comme dit plus haut, ca n'est pas possible étant donné que seul toi sait ce que doivent faire tes fonctions. Pour ma part, j'ai quand même automatisé la génération de mes classes de test : je fais une génération (assez naïve) depuis les classes du programme. Je dit assez naïve car j'ai fait la correspondance 1 classe de test, 1 TestFixture et 1 méthode de test, une méthode. Si je ne veux pas générer de test, je marque ma méthode ou classe pour que ca ne donne lieu à aucune génération.
    Concrètement, j'ai implémenté cette génération dans l'outil UML qui génère mes classes, donc si tu n'as pas de modèle (par modèle je veux dire modélisation UML de tes classes) à l'origine, ca ne te servira à rien... Mais bon, j'expose juste les choix que j'ai pris. Et je ne les regrette pas au fur et à mesure de mes tests... Ca prouve qu'ils sont pas trop pourris.

• # JUnit

  Posté par dripple le 14 juin 2004 à 16:25. Évalué à 0.

  

  Tu as JUnit pour le java
  
  http://www.junit.org(...)
  http://junit.sourceforge.net(...)
  
  Ouala ouala...

  • [^] # Re: JUnit

    Posté par Gawan le 14 juin 2004 à 16:45. Évalué à 1.

    

    combiné à Hibernate et middlegen, on obtient un outil très très puissant

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.