2011-01-13 7 views
6

Mam klasę, która łączy trzy inne usługi, zaprojektowane specjalnie w celu uczynienia implementacji innych usług bardziej modułowymi, ale większość mojej logiki testu jednostkowego znajduje się w fałszywej weryfikacji. Czy istnieje sposób na przeprojektowanie, aby tego uniknąć?Czy ma się test jednostkowy, który w większości przypadków jest fałszywą weryfikacją zapachu?

Python przykład:

class Input(object): pass 

class Output(object): pass 

class Finder(object): pass 

class Correlator(object): pass 
    def __init__(self, input, output, finder): 
    pass 
    def run(): 
    finder.find(input.GetRows()) 
    output.print(finder) 

I wtedy trzeba kpić wejściowego, wyjście i Finder. Nawet jeśli zrobię kolejną abstrakcję i zwrócę coś z Correlator.run(), to nadal będzie musiało zostać przetestowane jako próbna.

+1

Jaki jest dokładnie twój problem? Mam klasy, które wymagają maksymalnie ośmiu zależności ... jeśli twój projekt jest poprawny i uważasz, że twoje abstrakcje są spójne, nie zmieniłbym twojego kodu. – Simone

+0

Myślę, że przeszkadzało mi to, że jedynym celem klasy jest integracja, więc najlepszym sposobem na sprawdzenie tego będzie test integracyjny. Zawsze dążyłem do niezależnych testów jednostkowych, a następnie testów integracyjnych w miarę dojrzewania architektury. Chyba po prostu muszę odpuścić ten. – bluehavana

Odpowiedz

2

Po prostu zadaj sobie pytanie: co dokładnie musisz sprawdzić w tym konkretnym przypadku testowym? Jeśli to sprawdzenie nie polega na innych klasach, które nie są obojętne, to jesteś w porządku.

Jednak wiele makiet to zwykle zapach w tym sensie, że prawdopodobnie próbujesz przetestować integrację bez faktycznej integracji. Więc jeśli założysz, że jeśli klasa przejdzie test z mockami, to będzie dobrze pracować z prawdziwymi klasami, niż tak, musisz napisać więcej testów.

Osobiście nie piszę wielu testów jednostkowych. Jestem programistą i wolę testy funkcjonalne, które testują całą aplikację za pomocą żądań HTTP, tak jak robiliby to użytkownicy. Twój przypadek może być inny

2

Nie ma powodu, aby używać tylko testu jednostkowego - być może testy integracyjne byłyby bardziej użyteczne w tym przypadku. Prawidłowo zainicjuj wszystkie obiekty, użyj głównej klasy i sprawdź na (prawdopodobnie złożonych) wynikach. W ten sposób będziesz testować interfejsy, przewidywalność wyników i inne rzeczy, które są ważne w dalszym ciągu na stosie. Używałem tego wcześniej i stwierdziłem, że test trudny do integracji prawdopodobnie ma zbyt wiele atrybutów/parametrów lub zbyt skomplikowane/źle sformatowane wyjście.

0

Na pierwszy rzut oka wygląda na to, że poziom szyderstwa staje się duży. Jeśli używasz dynamicznego języka (zakładam, że tak, ponieważ twój przykład jest w Pythonie), spróbowałbym stworzyć podklasy klas produkcyjnych z najbardziej problematycznymi metodami, które zostałyby przesłonięte i przedstawiać wyśmiewane dane, więc uzyskać mieszankę produkcji i wyszydzony kod. Jeśli twoja ścieżka kodowa nie pozwala na tworzenie instancji obiektów, spróbowałbym monkey patching w metodach wymiany zwracających fałszywe dane.

Pogoda czy nie jest to zapach kodu zależy również od jakości wyśmiewanych danych. Wrzucanie do debuggera i kopiowanie wklejanych znanych poprawnych danych lub wykrywanie ich z sieci jest moim zdaniem najlepszym sposobem zapewnienia tego.

Integracja a testowanie jednostkowe to także ekonomiczne pytanie: jak bolesne jest zastąpienie testów jednostkowych testami integracyjnymi/funkcjonalnymi? Im większa skala systemu, tym więcej można uzyskać dzięki lekkim szyderstwom, a tym samym testom jednostkowym.

Powiązane problemy