Pisanie testów jednostkowych do kodu jest dziś powszechną praktyką, aczkolwiek nie dla wszystkich języków. Pisząc strony WWW, aplikacje desktopowe czy też mobilne przywykliśmy do tego, że tworzymy testy jednostkowe sprawdzające kod aplikacji. Natomiast nie robimy tego dla kodu napisanego w bazie danych. Po części dlatego, że używamy narzędzi ORM, które generują ten kod za nas. I wtedy nie ma rzeczywiście takiej potrzeby.
Inaczej wygląda sytuacja w momencie, gdy sami piszemy kod SQLa. Wtedy kod ten powinien zostać przetestowany na takich samych zasadach jak normalny kod produkcyjny. Jeśli nasza baza stoi na Microsoft SQL możemy do tego wykorzystać bibliotekę [mark]tSQLt[/mark]. Bibliotekę tę używa się bardzo prosto. Pozwala ona fakeować widoki, tabele, funkcje, jak również procedury składowane. Osoby bardziej zainteresowane tematem odsyłam na stronę biblioteki.
Przejdźmy więc do tematu. Mało osób wie, że dla kodu napisanego w SQLu można też wygenerować raport pokrycia. Służy do tego narzędzie [mark]SQLCover Code Coverage for SQL Server T-SQL[/mark]. Efektem uruchomienia jest raport:
Raport pokrycia kodu SQL testami jednostkowymi – podsumowanie
Raport pokrycia kodu SQL testami jednostkowymi – szczegóły
Aby otrzymać taki raport należy pobrać:
Po rozpakowaniu narzędzi należy je jeszcze skonfigurować. W tym celu wystarczy wprowadzić kilka zmian w pliku SQLCover.ps1. W tym pliku należy zdefiniować połączenie do bazy danych, podać ścieżkę do ReportGeneratora oraz ścieżkę definiującą miejsce zapisania raportów:
$result = Get-CoverTSql "SQLCover.dll" "server=.;integrated security=sspi;initial catalog=tSQLt_Example" "tSQLt_Example" "tSQLt.RunAll" Export-OpenXml $result "e:\testReport\" Start-ReportGenerator "e:\testReport\" "ReportGenerator\reportgenerator.exe"
I tyle. Po uruchomieniu skryptu zostanie wygenerowany raport pokrycia.
Narzędzie pomimo faktu, że generuje użyteczne informacje nie jest jeszcze do końca dopracowane. Pewną niewielką wadą jest pokazywanie, że kod odpowiadający za zdefiniowanie typów tabelarycznych nie został przetestowany pomimo jego wykonania. Powoduje to zaniżenie współczynnika pokrycia kodu testami.
Drugą większą niedogodnością jest traktowanie wyrażenia SELECT jako całości. Jeśli wyrażenie to ma skomplikowaną logikę (np. wiele warunków w sekcji WHERE) to wystarczy tylko raz je uruchomić a narzędzie wskaże, że wyrażenie to zostało przetestowane w 100% nawet wtedy gdy został pokryty tylko jeden przypadek testowy. Niestety wydaje mi się, że tego mankamentu nie uda się poprawić.
Zostaw komentarz