Scripts de base de données de tests unitaires

En acceptant la commodité d'utiliser des tests unitaires sur mon C ++ préféré, j'ai essayé de transférer mon expérience à TSQL, d'autant plus que le nouvel employeur aime une initiative utile sur le terrain et distribue des petits pains pour cela.

J'ai regardé à travers plusieurs cadres bien connus, je suis arrivé à la conclusion que, en règle générale, ils sont volumineux et apportent une syntaxe supplémentaire qui doit être étudiée en plus.

Certains cadres fonctionnent à merveille et plaisent à l'œil du gestionnaire, à qui ils sont montrés, mais présentent un certain nombre de limitations que je n'aimais pas.

Je voulais tout implémenter sur du TSQL pur casher-halal-orthodoxe.

De temps en temps, distrayant du développement principal pendant plusieurs années en affinant la structure du script, j'ai décidé de le partager avec vous (mais j'ai quand même réussi à produire 3,5 Mo de scripts).

Mes exigences de base étaient simples - je dois effectuer n'importe quel test unitaire dans un fichier sans avoir besoin de gestes et d'outils logiciels spéciaux - uniquement hardcore: sqlcmd ou MSSMS.

Aucune modification n'est apportée à la base de données dans laquelle le test est effectué - tout est restauré au début du script.

Un seul a défini une limite - le test devrait fonctionner dans une base de données vide (les données initiales peuvent l'être), sinon vous en aurez assez de démonter toutes les options.

La tâche principale consiste à tester la logique et à maintenir l'intégrité de la logique.

Pour cela, je mets la rubrique suivante au début du test:

SET QUOTED_IDENTIFIER ON GO PRINT '-------------------------------- CLR Unit tests for Habr Logic ---------------------------------' IF 0 < ( SELECT count(*) FROM device) begin RAISERROR ('FAILED: database must be empty for this unit test', 16, -1 ) end GO 

J'essaie de ne pas créer de tests unitaires plus longs que quelques écrans, bien que ce ne soit pas facile, dans le cas d'une logique complexe.

Un test unitaire typique ressemble à ceci et comporte 3 parties clés:

 BEGIN TRAN TestClr2 declare @test_name sysname = (select TOP 1 name from sys.dm_tran_active_transactions WHERE transaction_type = 1 ORDER BY transaction_begin_time DESC) + ' [fn_calculate_dev_status] record for device has wrong range' BEGIN TRY SET NOCOUNT ON; -- 1. prepare data for unit test insert into device (mli, oxygen, stamp ) values ('111', 5.55, getdate() ) -- 2. execute unit test -- SELECT dbo.fn_calculate_dev_status( 111, 0.1, 1.2) declare @result int = ( SELECT dbo.fn_calculate_dev_status( '111', 0.1, 1.2) ) END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_SEVERITY() AS ErrorSeverity, ERROR_STATE() AS ErrorState , @test_name AS ErrorProcedure, ERROR_LINE() AS ErrorLine, ERROR_MESSAGE() AS ErrorMessage END CATCH -- 3. result verification IF @result <> 0 RAISERROR ('FAILED: %s no data for device should be presented %d ', 16, -1, @test_name, @result ) ELSE print 'PASSED ' + @test_name ROLLBACK TRAN TestClr2 GO 

- 1. préparer les données pour le test unitaire

Ici, nous pouvons remplir les tableaux nécessaires avec des données et préparer des variables ou tableaux temporaires afin de ne pas encombrer le code dans la section de test.

- 2. exécuter le test unitaire

Ici, en règle générale, cela va, soit un appel de fonction, ou une procédure, ou un changement de table, si nous testons la logique de déclenchement.

- 3. vérification des résultats

Dans cette partie du test, nous vérifions comment l'état des objets de la base de données a changé, ou le résultat de la fonction-procédure testée.

Si la fonction de procédure renvoie un enregistrement, nous l'insérons dans la table temporaire et l'analysons déjà.

Les résultats agrégés et préparés sont comparés à la norme et lèvent une exception si tout le reste échoue.

Avec Oracle, tout est un peu plus compliqué - je ne pouvais pas écrire et exécuter le test sous cette forme et dans la même idéologie, plutôt à partir d'un peu d'expérience - nous avons cessé de supporter Oracle pour notre produit.

Chaque test unitaire est émis comme une procédure:

 CREATE OR REPLACE PROCEDURE UnitTest9_TRG_JOBLOGDETAIL AS v_message VARCHAR2(255) := 'UnitTest9_TRG_JOBLOGDETAIL: INSERT joblogdetail]- joblogdetail_result not Failed and joblogdetail_endtime is null '; v_maxdate date := '2014/01/01'; v_cnt NUMBER := 0; BEGIN savepoint my_savepoint; <b>-- 1. prepare data for unit test</b> insert into device ( dev_datecreated, dev_create_user, dev_ipaddress, dev_serialnumber , dev_productid, dev_manufacturer, dev_model, dev_id, dev_status, dev_functions) values (sysdate, 'Joe', '1.127.0.1', 'GSN-6238-N34', 'PRTF-452', 'Pinter Company', 'CM6003', 1, 1, 1 ); insert into joblog (JOBLOG_ID, joblog_starttime, joblog_progress) values (11, sysdate, 1); insert into joblog_template (JOBLOG_TEMPLATE_ID, joblog_id, joblog_templatename, joblog_templatetype) values (111, 11, N'joblog_template_test', 1); <b>-- 2. execute unit test</b> insert into joblogdetail ( JOBLOGDETAIL_ID, joblog_template_id, joblogdetail_function, joblogdetail_functiondetail, joblogdetail_result, joblogdetail_dev_id, joblogdetail_starttime, joblogdetail_endtime) values ( 1111, 111, 1, 1, 40, 1, v_maxdate, v_maxdate); <b>-- 3. result verification</b> SELECT count(dev_id) INTO v_cnt FROM device where dev_last_comm_time = v_maxdate; IF 1 <> v_cnt THEN DBMS_OUTPUT.PUT_LINE( 'FAILED: ' || v_message || ': Should not be update dev_last_comm_time: ' || TO_CHAR(v_maxdate)); ELSE DBMS_OUTPUT.PUT_LINE( 'PASSED: ' || v_message ); END IF; rollback to my_savepoint; END; / 

Dans le même fichier de test à la fin, vous devrez effectuer un nettoyage de la base de données à partir des tests créés et exécutés.

 commit; / set serveroutput on; SET FEEDBACK OFF; spool C:\dist\test.spl; exec UnitTest_empty_database; exec UnitTest3297_TRGBFR_UDEVICE(1); exec UnitTest5_TRG_BF_UDEVICE; exec UnitTest_3062a; ... spool off; / DROP PROCEDURE UnitTest_3062; DROP PROCEDURE UnitTest_BIRDIESEC_3344; DROP PROCEDURE UnitTest_empty_database; ... SET FEEDBACK ON; commit; 

C'est tout.

Ensuite, vous produisez simplement des fichiers, divisés en catégories du type: déclencheurs, fonctions, procédures, rapports, objets volumineux et spéciaux de logique métier, et bien sûr, pour chaque objet de base de données.

Presque tous les développeurs de bases de données froncent les sourcils et disent - pourquoi devrais-je, laissez les testeurs le faire. Si la base de données n'a aucune logique du mot, alors je suis d'accord avec eux, mais s'il y en a beaucoup, alors ils économisent naturellement les nerfs, la réputation et l'argent.

Un exemple.

Nous avons dans l'interface Web des arborescences de connexions logiques entre des objets arborescents comme l'Amérique -> Canada -> Ontario -> Waterloo, Asie -> Japon -> Tokyo -> Ebina, c'est-à-dire toute une série de bureaux géographiques.

Chacun de ces nœuds a des règles très complexes, l'utilisateur ou la règle ou le générateur attribue des périphériques.

En conséquence, même les instructions décrites en détail dans les étapes démolissent tout le monde, même ceux qui ont participé à la discussion et au développement de cette logique.

Plus de cinquante étapes de l'instruction avec différents ensembles de données - tout est documenté en détail.

Tout changement ou ajout à la logique est une horloge de vérification manuelle que rien ne s'est cassé.
Le refactoring de la mort est similaire.

Après avoir couvert la logique avec des tests unitaires, tout est vérifié par la soie et je suis sûr que tout fonctionne comme il se doit.

Tout développeur Java ayant recours à moi, lançant du tonnerre et des éclairs (en pensant à mes mains tordues) est facilement mis en place en exécutant le test approprié.

Quelques minutes et tout le monde est satisfait. Tout changement de code fatal en mon absence me sera rapidement signalé par mail.

Naturellement, en tant que paresseux, j'ai décidé d'automatiser tout pour l'automatisation continue et j'ai écrit du porridge à partir de lots et de python.

Je vous demande d'exécuter légèrement, dans le développement quotidien de près d'une douzaine de langages et d'environnements entre lesquels vous devez sauter, il y a un manque de temps catastrophique pour tout lécher et le mettre dans un look professionnel.

Je ne voulais pas tout faire sur Windows PowerShell - nos sauts fonctionnent toujours ici et là sur Windows 95 intégré.

Je voulais faire tous les appels en Python, mais il s'est avéré que certaines constructions sql (XML-parsing inside cte) ne sont pas prises en charge non seulement dans la bibliothèque python, mais aussi dans .NET, j'ai donc commencé le script via sqlcmd.

Le code est affiché ici .

Pour exécuter un exemple de travail, modifiez simplement 2 fichiers: smtppart.py et config.ini - nom du serveur SMTP, port et e-mail où les messages d'erreur seront supprimés.

Les scripts essaient d'abord d'obtenir les dernières mises à jour de svn (remplacez-les par les vôtres - git, perforce, ...).

Ensuite, une base propre est créée à partir de scripts avec un nom aléatoire, des tests unitaires y sont lancés, puis la base est supprimée.

La création d'une base de données de scripts de 80 Mo et de tests de 3,5 Mo (l'essentiel du schéma était déjà fait avant de rejoindre l'entreprise, donc je n'ai testé que ma partie) se fait sur ma machine en 15 minutes environ. J'ai juste le temps de boire une tasse de café avant le dernier engagement.

S'il y a eu des erreurs, les résultats de l'erreur seront envoyés par e-mail.

L'installation des dépendances est décrite dans le fichier: readme.txt

Après chaque modification de code, vous devez définir manuellement le hachage de code (il sera visible dans la ligne de commande) dans le fichier config.ini - le message apparaîtra même si le code est modifié et rien n'est cassé - afin que je puisse contrôler les modifications dans le code afin de pouvoir vérifier les modifications sans mon implication préalable.



Le lancement de tous les tests unitaires dans le fichier autorun.bat peut être placé dans le Planificateur de tâches Windows pour s'exécuter 1 à 2 par jour avant la création de l'entreprise ou après avoir quitté la maison - si quelque chose se casse le soir - vous pouvez regarder ce qui s'est passé devant le téléviseur et le réparer rapidement.

Je sais que dans les tests unitaires, il est le plus difficile de tout configurer, puis il est facile et agréable d'écrire des tests, même si cela peut être difficile et difficile, mais nécessaire. Bonne chance dans les tests, j'espère que mes conseils aideront quelqu'un.

Je serai heureux de prendre conseil si quelque chose peut être amélioré quelque part et de peigner le code, ne jugez pas strictement.