TDD z funkcjami SQL i manipulowania danymi

Chociaż jestem profesjonalnym programistą, nigdy nie zostałem formalnie przeszkolony w zakresie inżynierii oprogramowania. Ponieważ często tu odwiedzam i SO, zauważyłem trend pisania testów jednostkowych, gdy tylko jest to możliwe, a ponieważ moje oprogramowanie staje się bardziej złożone i wyrafinowane, automatyczne testowanie uważam za dobry pomysł na pomoc w debugowaniu.

Jednak większość mojej pracy polega na pisaniu złożonego kodu SQL, a następnie przetwarzaniu danych wyjściowych w jakiś sposób. Jak napisałbyś test, aby upewnić się, że na przykład SQL zwraca prawidłowe dane? Powiedzmy, że jeśli dane nie były pod twoją kontrolą (np. Systemu innego producenta), w jaki sposób możesz skutecznie przetestować swoje procedury przetwarzania bez konieczności ręcznego pisania ryz atrapy danych?

Najlepszym rozwiązaniem, jakie mogę wymyślić, jest przeglądanie danych, które łącznie obejmują większość przypadków. Następnie mogę połączyć te widoki z moim SQL, aby zobaczyć, czy zwraca poprawne rekordy i ręcznie przetworzyć widoki, aby zobaczyć, czy moje funkcje itp. Robią to, co powinny. Mimo to wydaje się nadmierny i płatkowaty; w szczególności znalezienie danych do przetestowania ...

Ważną zasadą testowania wszystkiego, co dotyczy bazy danych, jest całkowite odizolowanie jej od reszty aplikacji.

Architektura portów i adapterów jest naprawdę dobrym przykładem. Baza danych jest traktowana jako zewnętrzna wtyczka poprzez adapter do twojej aplikacji. To samo dotyczy wszystkich podsystemów innych firm. Aby przetestować zachowanie aplikacji i zinterpretować odpowiedzi podsystemów innych firm, jedyny sposób, w jaki wiem, jak to przetestować, to wyciąć odpowiedzi z tego podsystemu. Niekoniecznie oznacza to, że trzeba ręcznie zapisać wszystkie obiekty danych. Możesz łatwo zastosować podejście oparte na testowaniu opartym na danych.

Jeśli chodzi o testowanie interakcji aplikacji z bazą danych, możesz sfałszować adaptery bazy danych, aby na przykład użyć bazy danych w pamięci.

Teraz testujemy zapytania do bazy danych. Przede wszystkim wszystkie złożone zapytania powinny być rozkładane na łatwiejsze, proste i przewidywalne zapytania. To samo, co zrobiłbyś dla klasy tłuszczu lub funkcji tłuszczu. Istnieją narzędzia, które mogą pomóc w testowaniu bazy danych, takie jak Dbunit. Proste podejście, które czasem stosuję, polega na zastosowaniu koncepcji testów charakteryzacyjnych. Ustawiłbym więc bazę danych w znany stan, uruchomiłem wszystkie zapytania, które muszę zapisać, zapisując dane wyjściowe w miejscu (plik, pamięć) i uważam, że dane wyjściowe są prawidłowe. Kolejne przebiegi porównałyby ich wyniki z tym, więc zdecydowanie zaoferowałoby mi potrzebne testy regresji. Rzeczywiście, pierwsze wyjście nie jest gwarantowane, ale problem regresji można rozwiązać w ten sposób. Jeśli masz dobrze rozłożone zapytania, możesz je przetestować indywidualnie w bazie danych, która jest w znanym stanie.

To interesujące pytanie, ponieważ baza danych jest zwykle częścią, która jest fałszowana podczas testowania jednostek aplikacji. Mamy nadzieję, że logika samego silnika bazy danych jest dobrze przetestowana przez dostawcę, ale oczywiście zapytania, schemat i procedury przechowywane są kodem, który należy przetestować i zabezpieczyć przed regresją. Często jest to pozostawione testom integracyjnym, które nie są TDD.

Widoki byłyby prawdopodobnie trudnym sposobem, aby to zrobić, ponieważ tak naprawdę nie nadają się do pierwszego automatycznego testu na czerwone światło, zielone światło dla jednego aspektu na test, który jest preferowany w TDD. Również w widokach nie można najpierw napisać testu przed kodem. Lepszym rozwiązaniem byłoby napisanie procedur przechowywanych, w których można dodać do procedury logikę „aser” (np. Użycie instrukcji „if”) w celu przetestowania danych wyjściowych pod kątem awarii. Musisz przetestować tylko jedną rzecz w każdym teście jednostkowym, aby wyodrębnić jednostkę, a metoda SP byłaby do tego bardziej odpowiednia. Ponadto za pomocą SP można uruchomić cały ich pakiet jako skrypty podczas opracowywania kodu początkowego, a później podczas testowania regresji podczas refaktoryzacji.

Pamiętaj również, że testy muszą być powtarzalne i będziesz potrzebował kilku skryptów, aby zainicjować i zburzyć stan bazy danych, aby upewnić się, że stan jest taki sam dla każdego testu jednostkowego.

W przypadku pytania dotyczącego danych, które nie są pod kontrolą, jest to trudny obszar. Myślę, że lepiej jest naśmiewać się z fałszywych danych i testować wyjątki i warunki brzegowe w jak największym stopniu dla testów jednostkowych. W przeciwnym razie będzie bardziej należał do kategorii testów integracyjnych (co również jest dobrym rozwiązaniem). W przypadku testów integracyjnych możesz uruchomić testy z danymi innych firm i pozwolić, aby wygenerowało to wyjściowe dane wyjściowe, a dla kolejnych testów (np. Po refaktoryzacji) upewnij się, że te dane wyjściowe powtarzają znane dane wyjściowe.

W pewnym momencie będziesz potrzebować danych testowych. Jeśli korzystasz z systemu innej firmy, schemat został już utworzony, ale musisz uwzględnić przyszłe zmiany. Mamy nadzieję, że możesz uzyskać te zmiany z dokumentacji aktualizacji, ale możesz być zmuszony do samodzielnego porównania wersji bazy danych.

Oczekiwane zestawy wyników można zapisać w tabelach bazy danych lub zewnętrznych plikach / arkuszach kalkulacyjnych. Widziałem nawet używane CHECKSUM lub porównanie. Podczas testowania widoku / sproca wystąpi błąd, ponieważ nie istnieją. Następnie tworzysz obiekt z wystarczającą ilością kodu, aby przynajmniej wykonać (WYBIERZ -1 jako [błędne_dane];), a otrzymasz błąd, ponieważ nie pasuje on do zestawu wyników. Gdy się dopasują, masz zielone światło.

Zacząłem współpracować z właścicielami projektów i poprosić ich, by wyśmiewali raporty w arkuszu kalkulacyjnym i próbowali wymyślić dla mnie częściowe dane (dane wynikowe można umieścić w tabeli testowej). Na początku było pewne odepchnięcie, ale zdali sobie sprawę, że utworzę raport i i tak będą musieli to zweryfikować. Pozwoliło to zaoszczędzić czas na dłuższą metę. Jeśli chcą złożyć wniosek o zmianę, mogą ponownie wykonać arkusz kalkulacyjny. Teraz mogą odpowiedzieć na pytanie: „Jak trudno byłoby dodać…?”

Jeśli twoją platformą bazy danych jest SQL Server, istnieje bardzo ładne bezpłatne narzędzie: tSQLt .

tSQLt to platforma do testowania jednostek bazy danych dla Microsoft SQL Server. tSQLt jest kompatybilny z SQL Server 2005 (wymagany Service Pack 2) i nowszy we wszystkich wersjach.

Z powodzeniem wdrożyłem testowanie na poziomie bazy danych.

Niektóre kluczowe elementy, które sprawiają, że jest to tak przydatne, to:

• Możliwość pracy z fałszywymi tabelami i widokami, co zmniejsza normalną konfigurację
• Testy uruchamiają się automatycznie w transakcjach (tak łatwo można je ponownie uruchomić)
• Twoje twierdzenia mogą dokonywać porównań na tabelach (zarówno rzeczywistych, jak i fałszywych), dzięki czemu możesz sprawdzić, czy łatwo zmieniłeś jakiekolwiek dane