Testy danych sterowane danymi

Question

Jaka jest najlepsza praktyka w testowaniu interfejsu API, który zależy od danych z bazy danych? Na jakie problemy muszę zwracać uwagę w środowisku "Ciągłej integracji", które uruchamia testy jednostek w ramach procesu budowania? Chodzi mi o to, czy wdrożysz swoją bazę danych jako część skryptów budujących (może uruchomić twój instalator), czy też powinienem iść na dane zakodowane na stałe [użyj testów MSTest opartych na sterowaniu danymi z XML]?

Rozumiem, że mogę sfałszować warstwę danych dla warstwy Business Logic, ale co, gdybym miał problemy z instrukcjami SQL w DAL? Muszę trafić w bazę danych, prawda?

Cóż ... to jest torrent pytań:) ... Myśli?

Answer 1

O ile to możliwe, powinieneś wyszydzić kod, aby uniknąć trafienia w bazę danych, ale wydaje mi się, że masz rację co do potrzeby przetestowania kodu SQL w dowolnym miejscu. Jeśli piszesz testy, które trafiają do bazy danych, kluczową wskazówką do unikania bólu głowy jest upewnienie się, że twoja konfiguracja dostaje dane do znanego stanu, zamiast polegać na tym, że już są odpowiednie dane.

I oczywiście nigdy nie testuj w oparciu o bieżącą bazę danych! Ale to jest oczywiste :)

Answer 2

Jedną z rzeczy, którą zrobiłem, było stworzenie statycznych metod, które zwróciły dane testowe o znanym stanie. Następnie użyłbym "fałszywego" DAL, aby zwrócić te dane, tak jakbym faktycznie dzwonił do bazy danych. Jeśli chodzi o testowanie procedury sql/stored, przetestowałem ją za pomocą SQL Management Studio. YMMV!

Answer 3

Dobrym pomysłem jest automatyczne wyczyszczenie testowej bazy danych, a następnie zapełnienie jej danymi przewodów testowych, które zostaną uznane za dostępne dla wszystkich testów wymagających połączenia z bazą danych. Baza danych musi zostać zresetowana przed każdym testem w celu właściwego odizolowania - test, który powoduje błędy, może spowodować fałszywe niepowodzenia w następnych testach i stanie się nieprzyjemny, jeśli testy będą wykonywane w określonej kolejności, aby uzyskać spójne wyniki.

Możesz wyczyścić i wypełnić bazę danych narzędziami (DBUnit, DBUnit.NET, inne) lub po prostu utworzyć własne klasy narzędziowe, aby zrobić to samo.

Tak jak powiedziałeś, inne warstwy powinny być w wystarczającym stopniu oddzielone od klas, które faktycznie trafiają do bazy danych, więc potrzeba jakiegokolwiek rodzaju bazy danych biorącej udział w testowaniu jest ograniczona do testów przeprowadzanych na małym podzbiorze twojej bazy kodów. Twoje komponenty dostępu do bazy danych mogą być wyśmiewane/skrótowe dla wszystkiego, co zależy od nich.

Answer 4

Jak wspomniano, użyj szyderstwa do symulacji wywołań DB w testach jednostkowych, chyba że chcesz bez końca przeplatać swoje testy i dane. Testowanie instrukcji sql sugeruje więcej integration test. Uciekaj oddzielnie od testów jednostkowych, są to 2 różne bestie.