Vous pouvez jeter un coup d'œil aux classes de test unitaire disponibles dans notre section Unité de source ouverte SynCommons . Il est utilisé dans notre cadre Open-Source pour tous les tests de régression. Ce n'est peut-être pas le meilleur, mais cela vaut la peine d'y jeter un coup d'œil.
Ver http://blog.synopse.info/post/2010/07/23/Unit-Testing-light-in-Delphi
Afin d'implémenter un test unitaire, il suffit de déclarer un nouveau cas de test en créant une classe comme celle-ci :
type
TTestNumbersAdding = class(TSynTestCase)
published
procedure TestIntegerAdd;
procedure TestDoubleAdd;
end;
procedure TTestNumbersAdding.TestDoubleAdd;
var A,B: double;
i: integer;
begin
for i := 1 to 1000 do
begin
A := Random;
B := Random;
CheckSame(A+B,Adding(A,B));
end;
end;
Ensuite, vous créez une combinaison de test, et vous l'exécutez.
Dans la dernière version 1.13, il y a également un nouveau mécanisme de journalisation avec une trace de la pile de toute exception soulevée et autres, tout comme MadExcept, en utilisant le contenu du fichier .map comme source.
Il est maintenant utilisé par les classes de test unitaire, de sorte que tout échec créera une entrée dans le journal avec la ligne de source, et la trace de la pile :
C:\Dev\lib\SQLite3\exe\TestSQL3.exe 0.0.0.0 (2011-04-13)
Host=Laptop User=MyName CPU=2*0-15-1027 OS=2.3=5.1.2600 Wow64=0 Freq=3579545
TSynLogTest 1.13 2011-04-13 05:40:25
20110413 05402559 fail TTestLowLevelCommon(00B31D70) Low level common: TDynArray "" stack trace 0002FE0B SynCommons.TDynArray.Init (15148) 00036736 SynCommons.Test64K (18206) 0003682F SynCommons.TTestLowLevelCommon._TDynArray (18214) 000E9C94 TestSQL3 (163)
La différence entre une combinaison d'essai sans enregistrement et une combinaison d'essai avec enregistrement est uniquement la suivante :
procedure TSynTestsLogged.Failed(const msg: string; aTest: TSynTestCase);
begin
inherited;
with TestCase[fCurrentMethod] do
fLogFile.Log(sllFail,'%: % "%"',
[Ident,TestName[fCurrentMethodIndex],msg],aTest);
end;
Le mécanisme de journalisation peut faire beaucoup plus que simplement consigner les tests : vous pouvez consigner les appels récursifs des méthodes, sélectionner les informations que vous souhaitez voir apparaître dans les journaux, profiler l'application du côté client, écrire les propriétés publiées, le contenu de TList ou TCollection en tant que JSON dans le contenu du journal, et ainsi de suite...
La première fois que le fichier .map est lu, un fichier .mab est créé et contient toutes les informations nécessaires sur les symboles. Vous pouvez envoyer le fichier .mab avec le fichier .exe à votre client, ou même intégrer son contenu au fichier .exe. Ce fichier .mab est optimisé : un fichier .map de 927 984 octets est comprimé en un fichier .mab de 71 943 octets.
Ainsi, cette unité pourrait être reconnue comme l'enfant naturel du mariage de DUnit et de MadExcept, en pur OpenSource. :)
Des informations supplémentaires sont disponible sur notre forum . N'hésitez pas à demander. Les commentaires et les demandes de fonctionnalités sont les bienvenus ! Fonctionne de Delphi 6 jusqu'à XE.
0 votes
Il n'y a pas de remplacement automatique pour tester correctement les logiciels, à moins que le logiciel à tester ne soit devenu obsolète et qu'il n'y ait plus de développement (en général, les logiciels changent trop vite pour que les programmes/unités de test puissent les suivre). Les programmes de test eux-mêmes peuvent contenir des bogues. J'écris moi-même des mini-programmes de test pour tout ce que j'écris... rien ne peut le remplacer. Être un testeur serait une belle sécurité d'emploi, cela ne disparaîtra jamais ;) Pour moi, le "cadre de test unitaire" est totalement inutile. Appeler simplement toutes les méthodes et les parcourir manuellement est le meilleur moyen de déboguer.
11 votes
Contrairement à ce que @SkybuckFlying a dit plus haut, les tests unitaires automatisés sont la base pour tester correctement les logiciels. Les tests unitaires automatisés appropriés renforcent le couplage lâche et une bonne conception. "J'écris moi-même des mini-programmes de test pour tout ce que j'écris... il n'y a pas de remplacement pour cela." C'est exactement ce qu'est un cadre de test unitaire - un cadre pour écrire des programmes de test simples qui garantissent qu'un morceau de code donné se comporte comme prévu et rapporte les résultats d'une manière cohérente et automatisable.
0 votes
Quand je pense à "tester", je pense à "déboguer". Ce que vous décrivez ressemble plus à vérifier si le code se comporte selon des modèles existants... Je pense qu'il y a une différence entre... "vérifier ce qui était attendu"... et "explorer l'inconnu". Pour moi, l'investigation de l'inconnu est le débogage dans sa forme la plus vraie.
0 votes
Je m'oppose au terme "test unitaire automatisé". On dirait trop qu'il existe un outil magique pour générer automatiquement des programmes de test. D'après ce que je sais et ce que je peux dire, vous devrez écrire les programmes de test vous-même. Je ne vois pas du tout comment ce cadre ou tout autre cadre est censé vous aider à le faire... Un cadre de test réellement automatisé pourrait utiliser RTTI pour tester toutes sortes de variables, ce qui serait une meilleure définition du "test automatisé" ;)