fbpx

Testy z bazą danych – próby

Opublikowane przez Jerzy Wickowski w dniu

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.



Czy to był wartościowy artykuł? Zapisz się, a wyślę Ci dwa ebooki o czystym kodzie oraz będę informował Cię o nowych postach

2 Komentarze

Testy z bazą danych – założenia | Jerzy Wickowski · 2020-01-09 o 13:33

[…] przedstawiłem próby napisania testów jednostkowych do kodu używającego bazy danych. Opisałem dwa podejścia, które […]

Testy i baza danych - implementacja | Jerzy Wickowski · 2020-01-13 o 13:06

[…] opisałem genezę i założenia podejścia do testów z bazą danych. Pojawiła się tam tajemnicza klasa […]

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.


    Zapisz się

    Wyślę Ci dwa dokumenty mówiące o jakości kodu. Dodatkowo będę Cię informował o nowych postach i nowościach.