Journal Kaputt – une bibliothèque pour tester ses programmes Common Lisp

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
13
12
sept.
2020

Kaputt est une bibliothèque pour écrire les tests de programmes Common Lisp. Ses principales caractéristiques sont les suivantes:

  • Kaputt est simple, et ne définit que trois abstractions: les assertions les testcases et les protocols, en outre il n'ajoute aucun artefact dans les backtraces.

  • Kaputt est extensible, il est facile de définir des assertions spécifiques au problème résolu par le programme ce qui mène à des expressifs et informatifs.

  • Kaputt est taillé pour le développement interactif (Lisp oblige).

WWW: https://github.com/michipili/cl-kaputt

Les bibliothèques disponibles que j'ai pu tester (5AM, stefil, fiasco) ne satisfaisaient pas aux points suivants, c'est ce qui m'a poussé à écrire Kaputt.

(Petit point sympa, Kaputt définit les opérateurs de Knuth pour la comparaison des nombres en virgule flottante.)

Je suis ouvert à toutes vos suggestions, recommandations et questions, concernant ce code, son emploi et les fonctionnalités qui vous semblerait manquer.

J'aimerais bien produire une documentation en ligne, par exemple des fichier HTML ou des fichiers Markdown que je pourrais intégrer à mkdocs par exemple, ici encore toutes vos suggestions sont bienvenues!

Happy consing! ;-)

  • # coquille ?

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    ce qui mène à des (tests ?) expressifs et informatifs

  • # + de doc sur CL

    Posté par  . Évalué à 4.

    Salut,

    Belle petite librairie !

    Un peu plus de doc pour les curieux et curieuses:

    • [^] # Re: + de doc sur CL

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 14 septembre 2020 à 09:08.

      Ah cool, merci pour le commentaire encourageant et les détails! :-)

      J'ai vu que le “cookbook” présente PROVE comme obsolète, du coup il faudrait réécrire la section. Qu'est-ce que tu préconiserais comme paquet de référence pour le remplacer?

      • [^] # Re: + de doc sur CL

        Posté par  . Évalué à 2.

        Mais de rien :)

        Je tends fortement vers Rove (le successeur de Prove, par Fukamachi). J'ai éliminé Parachute récemment en l'essayant. Pour un choix "future proof" je pense qu'on a 5AM (très utilisé par les lispers) VS Rove. Or Rove a quelques fonctionnalités "modernes" par défaut, et c'est bien. Par exemple, possibilité de le lancer facilement depuis la ligne de commande.

        • [^] # Re: + de doc sur CL

          Posté par  (site web personnel) . Évalué à 2.

          Ah oui, maintenant je me souviens du gros problème que j'avais avec 5AM il y a deux ans, et la raison pour-laquelle j'ai écrit Kaputt (en plus du fait que je voulais mieux comprendre le traitement des erreurs).

          La raison est que lorsqu'un test du style

          (is (equal a b))

          n'est pas satisfait on a besoin de voir a et b, ce que montre 5AM et la plupart des outils analogues. Là où ça se corse, c'est lorsqu'on dévie de la forme la plus simple du test

          (is (prédicat-binaire attendu reçu))

          la macro is a besoin de savoir des choses sur le prédicat pour montrer intelligemment les arguments, par exemple si on a quelque chose comme:

          (is (prédicat-ternaire contexte-partagé attendu reçu))

          il faut faire des efforts pour montrer les arguments.

Suivre le flux des commentaires

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