Je viens de démarrer un nouveau projet Haskell et je voulais mettre en place un bon flux de travail de test depuis le début. Il semble que Haskell dispose de nombreux outils de test excellents et uniques et de nombreuses façons de les intégrer.
J'ai étudié:
Tout cela semble très bien fonctionner dans leurs domaines, mais je recherche une approche globale des tests et je me demande ce qui a bien fonctionné pour d'autres personnes.
Réponses:
Obtenir les bons tests unitaires, la couverture de code et les tests de performance consiste principalement à choisir les bons outils.
J'utiliserai comme exemple en cours d'exécution un package que je viens de commencer à activer avec les tests unitaires, la couverture de code et les benchmarks:
http://github.com/ekmett/speculation
Vous pouvez intégrer vos tests et benchmarks directement dans votre fichier cabal en leur ajoutant des sections et en les masquant derrière des indicateurs afin qu'ils ne le fassent pas pour que chaque utilisateur de votre bibliothèque ait accès à (et veuille l'utiliser pour lui-même) ) la version exacte des outils de test que vous avez choisis.
http://github.com/ekmett/speculation/blob/master/speculation.cabal
Ensuite, vous pouvez dire à Cabal comment exécuter votre suite de tests. Comme le test cabal n'existe pas encore, nous avons un étudiant qui travaille dessus pour l'été de code de cette année! - le meilleur mécanisme que nous ayons est Voici comment utiliser le mécanisme de crochet utilisateur de cabal. Cela signifie passer à une version `` personnalisée '' avec cabal et configurer un testHook. Un exemple de testHook qui exécute un programme de test écrit avec test-framework, puis applique hpc au profil, peut être trouvé ici:
http://github.com/ekmett/speculation/blob/master/Setup.lhs
Et puis, vous pouvez utiliser le framework de test pour regrouper les tests QuickCheck et HUnit dans un seul programme:
http://github.com/ekmett/speculation/blob/master/Test.hs
Le fichier cabal doit activer -fhpc pour activer le test de couverture de code, puis le testHook dans Setup.lhs exécute manuellement hpc et écrit sa sortie dans votre répertoire dist.
Pour l'analyse comparative, l'histoire est un peu plus manuelle, il n'y a pas d'option de «référence cabale». Vous pouvez câbler vos benchmarks dans votre crochet de test, mais j'aime les exécuter à la main, car Criterion a tellement d'options de rapports graphiques. Vous pouvez ajouter vos benchmarks au fichier cabal comme indiqué ci-dessus, leur donner des drapeaux de compilation séparés, les cacher derrière un drapeau cabal, puis utiliser Criterion pour faire tout le travail:
http://github.com/ekmett/speculation/blob/master/Benchmark.hs
Vous pouvez ensuite exécuter vos benchmarks à partir de la ligne de commande et obtenir des fenêtres contextuelles KDE avec des résultats de benchmark, etc.
Étant donné que dans la pratique, vous vivez de toute façon dans la cabale tout en développant du code Haskell, il est très logique d'y intégrer votre chaîne d'outils.
Edit : le support de test Cabal existe maintenant. Voir http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/developing-packages.html#test-suites
cabal testet cabal bench, le mélange HUnit, doctestet des quickchecktests basés avec des criterionrepères. Le code speculationest antérieur à cabal testet cabal bench.
L'approche préconisée dans RWH ch 11 et dans XMonad est approximativement:
Une fois que vos principaux invariants sont établis via QuickCheck, vous pouvez commencer la refactorisation, en déplaçant ces tests en invariants de type.
Pratiques pour soutenir vos efforts:
Le package de test-framework est vraiment génial. Vous pouvez facilement intégrer des tests HUnit et QuickCheck et obtenir des exécutables qui exécutent uniquement des suites spécifiées, en fonction d'indicateurs de ligne de commande, avec plusieurs cibles de sortie.
Les tests et le profilage sont cependant des bêtes différentes. Pour le profilage, j'ai mis en place un exécutable séparé qui souligne uniquement la section que vous souhaitez profiler, et en regardant attentivement les résultats des builds et des exécutions de profilage (avec -prof-auto-all pour la compilation et + RTS -p pour un runtime drapeau).
Pour les tests, je m'appuie sur les propriétés HUnit et QuickCheck et j'utilise Haskell Test Framework pour collecter automatiquement tous les tests unitaires et toutes les propriétés QuickCheck.
Avertissement: Je suis le principal développeur du Haskell Test Framework.
cabal benchmaintenant existe aussi.