Samorodov Fedor Anatolievici. Cum se testează și se depanează bazele de date
Testarea automată a codului aplicației este simplă și simplă. Și cum să testezi baza de date? Sau o aplicație care funcționează cu baza de date. La urma urmei, baza de date nu este doar cod de program, baza de date este un obiect care își păstrează starea. Și dacă vom începe să schimbăm datele din baza de date în timpul testelor (și fără asta, ce fel de testare vom avea?!), Atunci după fiecare test, baza de date se va schimba. Acest lucru poate interfera cu testele ulterioare și poate dăuna ireversibil bazei de date.
Cheia pentru rezolvarea problemei este tranzacțiile. Una dintre caracteristicile acestui mecanism este aceea că, atâta timp cât tranzacția nu este finalizată, puteți oricând să anulați toate modificările și să reveniți la starea de bază în momentul în care a început tranzacția.
- deschideți tranzacția;
- dacă este necesar, să efectueze acțiuni pregătitoare de testare;
- efectuați un test de unitate (sau rulați doar un script a cărui activitate dorim să o testați);
- verificați rezultatul scenariului;
- am anula tranzacția, returnând baza de date în starea inițială.
Chiar dacă există încă tranzacții neînchise în codul testat, ROLLBACK extern va răsturna în continuare toate modificările corect.
Ei bine, dacă trebuie să testați scriptul SQL sau procedura stocată. Și dacă testarea unei aplicații care se conectează la baza de date, deschiderea unei noi conexiuni? În plus, dacă facem o depanare, atunci cu siguranță ne dorim să privim baza de date prin ochii aplicației depanate. Cum să fii în acest caz?
Nu vă grăbiți să compuneți tranzacții distribuite, există o soluție mai simplă! Puteți deschide o tranzacție pe o singură conexiune prin instrumentele standard ale serverului SQL și o puteți continua pe cealaltă.
Pentru aceasta, trebuie să vă conectați la server, să deschideți tranzacția, să primiți simbolul acestei tranzacții și apoi să transferați acest token către aplicația testată. Se va alătura tranzacției noastre în sesiunea sa și de acum înainte vom vedea datele (și, de asemenea, vom simți blocările) în sesiunea de depanare exact așa cum le vede aplicația testată.
Secvența acțiunilor este următoarea:
Începând cu tranzacția în sesiunea de depanare, trebuie să ne cunoaștem identificatorul. Aceasta este o linie unică prin care serverul distinge între tranzacții. Acest identificator trebuie într-un fel să fie transmis aplicației testate.
Acum sarcina aplicației - înainte de a începe să facă ceea ce trebuie să facă - este legată de tranzacția noastră de control.
Apoi, aplicația începe să funcționeze, inclusiv pornirea procedurilor stocate, deschiderea tranzacțiilor, schimbarea modului de izolare. Dar sesiunea noastră de depanare se va afla în aceeași tranzacție cu aplicația.
Să presupunem că o aplicație blochează o tabelă și începe să modifice conținutul acesteia. În acest moment, nici o altă conexiune nu poate privi în masa încuiată. Dar nu sesiunea de depanare! Din aceasta, putem să vedem baza de date în același mod ca și o aplicație, deoarece serverul SQL crede că suntem în aceeași tranzacție.
În timp ce pentru toate celelalte sesiuni, acțiunile aplicației sunt ascunse prin blocări.
sesiunea de depanare trece în siguranță prin blocare (serverul crede că este propriile noastre încuietori)!
Sau imaginați-vă că aplicația începe să lucreze cu versiunea sa de linii în modul SNAPSHOT. Cum să te uiți în aceste versiuni? Chiar și acest lucru este posibil dacă sunteți conectat printr-o tranzacție comună!
Nu uitați să renunțați la tranzacția de control la sfârșitul acestui proces fascinant. Acest lucru se poate face atât din sesiunea de depanare (în cazul în care procesul de testare este finalizat în mod normal), cât și din aplicația însăși (dacă se întâmplă ceva neașteptat în ea).
Articole similare
-
La aceste propoziții principale, selectați clauzele relevante
-
Odbc devine cea mai bună soluție pentru accesarea datelor la nivel de întreprindere
-
A fost acoperit un hard disk, cum se recuperează datele de pe desktop
Trimiteți-le prietenilor: