Jak zachować bazę danych w pamięci, aby później użyć jej w teście jednostkowym

Question

W moim kodzie od czasu do czasu przekazywane są różne tablice bajtów i takie. Mogą to być również obiekty zarządzane. Chciałbym zachować te struktury pamięci, aby móc pisać przypadki testowe na konkretnych przykładach.

Moje standardowe podejście polega na trafieniu w punkt przerwania, skorzystaniu z debuggera w celu znalezienia różnych wartości, a następnie albo dodaniu ich do nowego lub osadzeniu pliku lub czegoś w zespole testowym jednostki jako zasobu. Czasami wymaga to napisania mojej własnej abstrakcji interakcji z komponentem, aby mój kod był zależny od czegoś, co może być nowe.

Czy jest łatwiejszy sposób? Nie mogę sobie wyobrazić, że to coś nowego. Powiedzmy, że dostałeś centralę ogniową, z którą możesz się komunikować. Grasz się z nim, aby wyprodukować datagramy, które chcesz utworzyć dla testów jednostkowych. Ponadto, gdy napotkasz błąd z powodu nieudokumentowanego sposobu, w jaki centrala przeciwpożarowa komponuje swoje złożone wiadomości, chcesz nagrać i zachować te przykłady.

Idealnie chciałbym móc nagrać wszystkie interakcje z moim kodem, a następnie wybrać i wybrać różne scenariusze odtwarzania. Ale właśnie pobranie różnych przykładów datagramów z pamięci do debuggera i umieszczenie ich w testach jednostkowych bardzo mi pomogłoby.

Wszelkie sugestie?

Answer 1

Spróbuj z binary serialization.

Powyższe dotyczy konkretnie części, w której chcesz zapisać/załadować informacje lub niektóre obiekty przechowujące informacje, których używasz do testowania interakcji z tym systemem zewnętrznym. Wolę nazwać te testy testami integracyjnymi, aby lepiej uchwycić różnicę ostrości od testów jednostkowych reszty kodu z inną logiką, którą możesz mieć.

Spróbuj oddzielić kod, który wykonuje konkretną integrację z systemem zewnętrznym od reszty kodu w systemie. Proponuję umieścić go za interfejsem, który można zastąpić/wyśmiewać podczas tworzenia testów jednostkowych dla reszty systemu. W ten sposób możesz stworzyć specjalnie zaprojektowane scenariusze, które testują kilka aspektów/logikę twojego kodu bez uderzania w system zewnętrzny - co również oznacza, że ​​możesz uruchomić ich wiele w kilka sekund.

Answer 2

Jak wskazuje Freddy Rios w swojej odpowiedzi, potrzebny jest sposób na zachowanie obiektu w pamięci, aby można go było ponownie wykorzystać w testach jednostkowych. Memento design pattern jest dobrym początkiem, a serializacja jest domyślnym sposobem .NET implementacji.

Pozostawia to pytanie, jak z łatwością przechwycić te obiekty. Oto podejście, które można wypróbować:

Streszczenie komunikacji do iz zasobu za interfejsem. To zawsze jest dobra decyzja dotycząca projektu.

Po wykonaniu tej czynności można użyć Decorator design pattern do zawinięcia rzeczywistej implementacji tego interfejsu. Oznacza to, że można utworzyć dekorator, który po prostu zapisuje (serializuje) interakcję, ale przekazuje wszystkie wywołania do podstawowej implementacji po zarejestrowaniu obiektów, o których mowa.

Podczas rozwiązywania problemów można podłączyć kod do Memento Decorator, a następnie odebrać pliki w dowolnym miejscu, w którym zostały napisane. Aby uzyskać kod produkcyjny, po prostu pomiń Memento Decorator i bezpośrednio użyj rzeczywistej implementacji.

Jeśli chcesz być naprawdę fantazyjne, można nawet wdrożyć Memento Dekorator tak, że jednostka emituje kod testowy, który naśladuje interakcji, który został nagrany, ale może to wymagać sporo wysiłku ...