Testy z bazą danych – próby

Opublikowane przez Jerzy Wickowski w dniu 2016-07-202016-07-20

Nadchodzi taki moment w życiu programisty, że poznaje testy i chciałby je stosować zawsze i wszędzie. Czy to dobrze, czy to źle? To już temat na zupełnie inną dyskusję. 

W każdym razie chciałem zacząć pisać testy jednostkowe kodu używającego bazy danych. Pierwsze próby były karkołomne i skazane na porażkę. Jednak każda następna okazywała się lepsza. Zapraszam do poznania mojej drogi do testowania kodu związanego z bazą danych.

Ścieżka pierwsza — listy, kolekcje, słowniki

Było to jeszcze pamiętnych czasów, gdy podejście CodeFirst nie było czymś oczywistym. Istniał natomiast plik EDMX oraz szablon t4 generujący kontekst i klasy encji. Zatem pomysł był prosty. Podepnę drugi szablon generujący interfejs kontekstu oraz jego nową implementację. Użyłem list zamiast standardowych DbSetów. Zadziałało! Nadszedł czas radości, euforii i pisania testów, ale… no właśnie. Rozwiązanie to nie było idealne. Brakowało w nim między innymi:

• Autoinkrementacji
• Tworzenia zależności po insercie
• Transakcji
• Interakcji z SaveChanges

Ścieżka druga — imitacja bazy w pamięci

Gdy nastały czasy bardziej współczesne, a CodeFirst rozgościł się na developerskich salonach. Kontekst i encje, nie musiały już być opisywane w EDMX i generowane. Dzięki czemu stały się bardziej otwarte na modyfikacje. Pomyślałem zatem, że zaimplementuję kontekst w stylu „InMemory”. 

Programowanie tego mechanizmu sprawiło mi ogrom frajdy i satysfakcji. Użyłem trochę refleksji i zmiennych dynamicznych. Po chwili już mogłem pisać testy jednostkowe. Udało się rozwiązać kilka niedoskonałości występujących w poprzednim rozwiązaniu. Przykładowo autoinkremetacja. Jednakże to wciąż nie było to rozwiązanie doskonałe, bowiem pozostawała masa rzeczy niepokryta testami. Takich jak transakcje, relacje, indeksy i inne rzeczy, które leżą po stronie bazy danych.

Ścieżka trzecia — testy integracyjne

Nauczony doświadczeniem moim oraz innych. Podjąłem decyzję, że tym razem podejdę do sprawy inaczej. Postawiłem na testowanie integracyjne. Z prawdziwą bazą danych, na żywo, bez mockowania. Wykonanie testów było zdecydowanie wolniejsze, jednak testowało dokładnie to co było używane w aplikacji, a nie jakąś atrapę typu „In Memory”. Na chwilę ówczesną sprawdziło się doskonale.

Miałeś kiedyś podobny problem? Udało Ci się go rozwiązać? W jaki sposób? Opisałem swoje rozwiązanie na tu i tu. Jeżeli masz jakieś sugestie lub pytania to zapraszam serdecznie do dyskusji.