L'argument est : c'est génial, plutôt que perdre du temps à compiler, vérifier les warnings, les erreurs et enfin les résultats, on fait tourner le code dans un interpréteur (UnderC) et ensuite on le compile (gcc).
Je ne suis pas d'accord avec cette approche : elle n'est pas répétable : qui dit que l'interpréteur se comporte de la même façon que le compilateur ? Et pour les performances ?
C'est intéressant pour simplement tester une fonctionnalité, mais pas pour tester le code.
Une meilleure méthode (a mon humble avis) :
1 écrire une spec propre.
2 à partir de cette spec, écrire un script de test (une moulinette)
3 écrire le code
4 compiler le code
5 faire tourner la moulinette sur le code.
Alors voilà, je vous présente l'outil que certains de mes collègues et moi utilisons et qui est bien pratique : je vous laisse aller voir le site qui est très bien fait et qui vous présentera tout cela bien mieux que moi.
Aller plus loin
- DART (15 clics)
- DLFP : « UnderC : un interpréteur c++ » (3 clics)
# Re: Dart, un environnement de test
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
# Re: Dart, un environnement de test
Posté par matiphas . Évalué à 1.
# Re: Dart, un environnement de test
Posté par Belegar . Évalué à 1.
# Re: Dart, un environnement de test
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
C'est un truc pour faire des tests de non-reg je crois.
[^] # Re: Dart, un environnement de test
Posté par matiphas . Évalué à 2.
- il est nettement moins facile a mettre en oeuvre
- il ne propose pas de clickodrome (interface conviviale) pour les resultats de tests.
[^] # Re: Dart, un environnement de test
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.