Cum pot verifica persistența unității?
Ca novice în practicarea dezvoltării bazate pe teste, deseori mă întâlnesc într-o problemă în ceea ce privește modul de a trata unitatea de persistență într-o bază de date.
Știu că, din punct de vedere tehnic, acest lucru ar fi un test de integrare (nu un test unitar), dar vreau să aflu cele mai bune strategii pentru următoarele:
- Testarea interogărilor.
- Testarea inserțiilor. De unde știu că inserția care a greșit în cazul în care nu reușește? Îl pot testa prin introducerea și apoi interogarea, dar cum pot să știu că interogarea nu a fost greșită?
- Testarea actualizărilor și ștergerilor - la fel ca și inserările de testare
Care sunt cele mai bune practici pentru a face aceste lucruri?
În ceea ce privește testarea SQL: Sunt conștient de faptul că acest lucru se poate face, dar dacă folosesc un Mapper O / R ca NHibernate, el atribuie niște negii numelici în aliatele folosite pentru interogările de ieșire și întrucât este oarecum imprevizibil, nu sunt sigur Am putut testa pentru asta.
Trebuie doar să abandonez totul și să am încredere în NHibernate? Nu sunt sigur că e prudent.
Faceți testarea unității deranjând conexiunea bazei de date. În acest fel, puteți crea scenarii în care anumite interogări în fluxul unui apel de metode reușesc sau nu. De obicei, îmi construiesc asteptările mele false, astfel încât textul interogării efective să fie ignorat, pentru că într-adevăr vreau să testez toleranța la erori a metodei și modul în care se ocupă de ea însăși - specificul SQL este irelevant în acest scop.
Evident, acest lucru înseamnă că testul dvs. nu va verifica faptul că metoda funcționează , deoarece SQL poate fi greșit. Aici intră testele de integrare. Pentru asta, mă aștept ca altcineva să aibă un răspuns mai amănunțit, căci încep să mă confrunt cu ei înșiși.
De asemenea, aș bate jocul în baza de date și verificați dacă interogările sunt cele așteptate. Există riscul ca testul să verifice un sql greșit, dar acest lucru ar fi detectat în testele de integrare
Problema pe care am experimentat-o atunci când unitatea de testare persistență, mai ales fără un ORM și, astfel, batjocorirea bazei dvs. de date (conexiune), este că nu știi cu adevărat dacă interogările tale reușesc. Ar putea fi faptul că interogările dvs. sunt proiectate special pentru o anumită versiune de bază de date și reușesc doar cu acea versiune. Nu veți afla niciodată acest lucru dacă vă bateți baza de date. Deci, în opinia mea, persistența unității de testare este de doar o utilizare limitată. Ar trebui să adăugați întotdeauna teste care rulează împotriva bazei de date direcționate.
Pentru codul NHibernate , aș fi sfătui doar să bat joc NHibernate API pentru testele unității - să aveți încredere în bibliotecă pentru a face ceea ce trebuie. Dacă doriți să vă asigurați că datele se află de fapt în DB, efectuați un test de integrare.
Din punct de vedere tehnic, testele de rezistență ale persistenței nu sunt teste de unitate, ci sunt teste de integrare.
Cu C # folosind mbUnit, pur și simplu utilizați atributele SqlRestoreInfo și RollBack
[TestFixture]
[SqlRestoreInfo(, ,]
public class Tests
{
[SetUp]
public void Setup()
{
}
[Test]
[RollBack]
public void TEST()
{
//test insert.
}
}
Același lucru se poate face în NUnit, excpet numele de atribute diferă ușor.
În ceea ce privește verificarea dacă interogarea dvs. a fost de succes, în mod normal, trebuie să o urmați cu o a doua interogare pentru a vedea dacă baza de date a fost modificată așa cum vă așteptați.
Uită-te în unitatea DB. Este o bibliotecă Java, dar trebuie să existe un echivalent C #. Vă permite să pregătiți baza de date cu un set de date pentru a ști ce este în baza de date, apoi puteți interfața cu unitatea DB pentru a vedea ce este în baza de date. Se poate rula împotriva mai multor sisteme de baze de date, astfel încât să puteți utiliza configurația actuală a bazei de date sau să folosiți altceva, cum ar fi HSQL în Java (o implementare de bază de date Java cu o opțiune în memorie).
Dacă doriți să testați că codul dvs. utilizează corect baza de date (ceea ce este cel mai probabil să faceți), atunci acesta este calea de parcurs pentru a izola fiecare test și pentru a vă asigura că baza de date a pregătit datele.
Am scris un post despre unitate de testare stratul de date care acoperă această problemă exactă. Îmi cer scuze pentru fișa (rușinoasă), dar articolul este prea lung pentru a putea posta aici.
Sper că vă ajută - a funcționat foarte bine pentru mine în ultimele 6 luni pe 3 proiecte active.
Salutari,
Rob G
După cum a spus Mike Stone , DbUnit este excelent pentru a obține baza de date într-o înainte de efectuarea testelor. Când testele sunt terminate, DbUnit poate pune baza de date înapoi în starea în care a fost înainte, înainte de a efectua testele.
De obicei, creez un depozit și folosesc asta pentru a-mi salva entitatea, apoi recupera una nouă. Apoi afirm că recuperatul este egal cu cel salvat.
Pentru proiectele bazate pe JDBC, poate fi utilizat cadrul Acolyte: http://acolyte.eu.org . Permite accesul la date de tip mockup pe care doriți să îl testezi, beneficiind de abstractizarea JDBC, fără a trebui să gestionați un test specific DB.