Jak pisać testy pod nadal rozwijany, ale opuszczony projekt?

Uczestniczę w projekcie, którego jednym z elementów jest przepisanie black boxa, dla którego:
a) znam interfejs wejściowy, jest dobrze udokumentowany
b) mam częściowy opis interfejsu wyjściowego (struktura)
c) mam przykłady działania black boxa: wejście + wyjście
d) gruboziarniste reguły biznesowe są znane*

Realia projektowe:

• klient poobrażany z poprzednim dostawcą
• szczątkowa dokumentacja blackboxa (brakuje opisu zmian z kiklu ostatnich lat developmentu :-) )
• blackbox, jak to oprogrmowanie, zawiera błędy, więc czasem generuje niepoprawne dane
• po stronie klienta brakuje wiedzy domenowej ("szkoda, że X odszedł, znał sie na tym", "nie wiemy czemu tak wygenerowało")

Prace postępują (development odbywa się iteracyjnie i przebiega mniej więcej tak:

• weź próbkę Input+Output
• zaimplementuj gruboziarnistą regułę
• wygeneruj porównanie OLD vs NEW dla próbki (X% różnic na elemencie: X->Y->Z)
• gruboziarnista reguła nie działa dla 80% przypadków
• spotkanie -> omówienie skąd może wynikać różnica -> ustalenie innej reguły
• kolejna iteracja

Jakbyście podeszli do testów jednostkowych w takiej sytuacji?

sytuacja jakoś nie wpływa jak pisać testy IMO. Dostajesz wymagania i pod nie piszesz kod a ze jest duża dynamika zmian przez brak pewności co do wymagań to trudno. W momencie pisania nie wiesz co zostanie a co będzie zaorane. Jak frustruje cię wyjebywanie napisanego dopiero co kodu może opóźniać pisanie testów. Wiem ze purysci zabijają za takie opinie. Ale dla mnie testy to jest narzędzie upraszczające prace a nie cel sam w sobie. Jednorazowo to mogę manualnie przetestować każda linijkę bez utraty jakości produktu.

Tak jak zawsze tj. starałbym się pisać jak najwięcej testów wyższego poziomu a jednostkowych jak najmniej (zależy jak jednostkę rozumieć...). Jeśli test jest dosyć prosty do zmiany to nie widzę powodów do zmiany. Natomiast jeśli zakres zmian jest duży to i tak testy zaoszczędzą czas na testowanie manualne i wyłapią więcej bugów niż ja sam

yarel napisał(a):

Jakbyście podeszli do testów jednostkowych w takiej sytuacji?

Jak to "jak"? Normalnie. Nie widzę tutaj nic niestandardowego.

Riddle napisał(a):

...
Jak to "jak"? Normalnie. Nie widzę tutaj nic niestandardowego.

Jaki test napisałbyś dla "reguły" - "Wpisy muszą być uporządkowane tak jak jest w obecnym rozwiązaniu" i jaka byłaby jego wartość?

Bierzecie tego black box'a, przygotowujecie zbiór wymagań, wysyłacie je klientowi z prośbą o potwierdzenie, jak to zrobi, to piszecie testy na wysokim poziomie i dopisujecie do tego już swoją nową implementację, już z normalnym podejściem jeżeli chodzi o testy. Jak się okaże, że jakieś wymaganie zostało zdefiniowane źle, albo w sposób niepełny, to wspólnie z klientem je uzupełniacie, zmieniacie testy, zmieniacie implementację.
W Internecie jest w cholerę treści o "odwróconej piramidzie testów".

Niestety, o ile podejście jest w teorii proste,. to w praktyce już gorzej, bo nawet mając działającą aplikację nie zawsze wiesz, że ona coś robi, a nawet jak się dowiesz, to nie wiesz dlaczego. No i "zróbcie tak samo jak w tym co mamy" jest pakowaniem się w kanał, bo właściwie oznacza, że aktualnie istniejące błędy stają się wymaganiami. Czyli moim zdaniem, jedyna sprawdzona droga do sukcesu, to jak najszybsze uświadomienie klientowi, że bez sensownych wymagań z jego strony zabawa się nie uda.

yarel napisał(a):

Riddle napisał(a):

...
Jak to "jak"? Normalnie. Nie widzę tutaj nic niestandardowego.

Jaki test napisałbyś dla "reguły" - "Wpisy muszą być uporządkowane tak jak jest w obecnym rozwiązaniu" i jaka byłaby jego wartość?

To nie jest programistyczne wymaganie, w takiej formie w jakiej jest sprezentowane.

Musisz to przetłumaczyć na bardziej imperatywne podejście. Krok pierwszy byłby: "jak są uporządkowane w tym obecnym projekcie?". Nie jesteś w stanie napisać dobrego testu pod coś, co nie wiesz jak ma działać. A wygląda mi to jakbyś własnie nie wiedział jak ten wynikowy projekt ma działać - wiadomo tylko że "tak jak w starym", ale to nie jest wystarczające info.

Ja bym do tego podszedł od drugiej strony - odrzuciłbym całkowicie podejście "ma działać tak jak w obecnym", i zacząłbym po prostu od zebrania nowych wymagań.

Riddle napisał(a):

...
To nie jest programistyczne wymaganie, w takiej formie w jakiej jest sprezentowane.

Z tym się zgadzam, ale taka sytuacja :-)

Musisz to przetłumaczyć na bardziej imperatywne podejście. Krok pierwszy byłby: "jak są uporządkowane w tym obecnym projekcie?". Nie jesteś w stanie napisać dobrego testu pod coś, co nie wiesz jak ma działać. A wygląda mi to jakbyś własnie nie wiedział jak ten wynikowy projekt ma działać - wiadomo tylko że "tak jak w starym", ale to nie jest wystarczające info.

Jak wyżej. Krok pierwszy ("jak są uporządkowane w tym obecnym projekcie?") pokazał po kilku blokach spotkań, że "nie wiadomo" (nie ma kogoś kto by chciał/musiał się podpisać pod takim wymaganiem, że ma być w kolejności X/Y/Z).

Ja bym do tego podszedł od drugiej strony - odrzuciłbym całkowicie podejście "ma działać tak jak w obecnym", i zacząłbym po prostu od zebrania nowych wymagań.

Tu realia są takie, że nie masz sprecyzowanych wymagań, a raczej postawiony "cel". Po stronie klienta nie ma ludzi, którzy je przed laty definiowali :-) Jest powszechne zrozumienie trudności sytuacji. Zakładam, że szukamy sposobu (żeby zrobić), a nie powodu (żeby nie robić) i mamy ograniczenia w postaci braku wiedzy domenowej. Można rozważać temat dobrych praktyk, jak by to zrobić wzorcowo itp. Prace postępują, wynik generowany jest coraz bliższy wersji oryginalnej.

Natomiast post dotyczy samego podejścia do testów jednostkowych w takiej patologicznej sytuacji. Gdzie wartość z ich tworzenia?

Może źle oceniam, ale wydaje mi się, że wyrzucanie czyjejś pracy do kosza może działać frustrująco i demotywująco.
Wolę dać ludziom w zespole bardziej rozwojowe zadania zamiast "weź napisz test, i tak go wyrzucimy za 2 dni". Czas zaoszczędzony można przeznaczyć na coś innego.

Jak wyżej. Krok pierwszy ("jak są uporządkowane w tym obecnym projekcie?") pokazał po kilku blokach spotkań, że "nie wiadomo" (nie ma kogoś kto by chciał/musiał się podpisać pod takim wymaganiem, że ma być w kolejności X/Y/Z).

Zgadzam się @Riddle - nie da się fizycznie napisać testu, nie wiedząc, jakie ma być zachowanie. Tutaj jest jak dla mnie oczywista sprzeczność i nie wiem o czym tutaj gadać.

Ale - jeśli faktycznie klient chce "tak jak w starym" - ok spoko, to już jakieś mgliste wymaganie jest. Wyjaśniłbym klientowi, że jeśli on nie wie, to ja postaram się na podstawie X ilości danych wejściowych spróbować na miarę swojej spostrzegawczości, stworzyć jakiś zestaw reguł który być może decyduje o tej kolejności (może są posortowane alfabetycznie, a może decyduje o tym kolejność zapisów, a może...) A następnie napisać testy dla tych danych wejściowych, czy wynik się zgadza. Ale absolutnie nic nie gwarantować, nic nie obiecywać, a powinno to przejść - skoro jak mówisz, jest "powszechne zrozumienie sytuacji".

Jest jeszcze coś takiego jak triangulacja, można jej użyć żeby zebrać info o aktualnym systemie, i przy jego użyciu napisać nowy.

Nie wiem, ale się wypowiem.

Zamiast w automaty kasę przeznaczyłbym na ludzi, którzy mieli by większe szanse zrozumieć skąd biorą się wyniki i dlatego właśnie takie. Od tych ludzi również oczekiwałbym dodatkowej weryfikacji co możemy zrobić lepiej, a czego nie powielać. Im lepsze głowy tym lepsze wnioski, pomysły i tym samym mniejsza szansa, że trzeba będzie poprawiać projekt w jakimś większym stopniu.

Testerami przez jakiś czas uczyniłbym te osoby, które robiłyby analizę, aby cały czas widzieli co się dzieje, a potem zamiast robić pełne testy od A do Z, robiłbym dla tych ludzi pomocnicze skrypty, które przyspieszą im pracę w dalszej analizie danych.

Dopiero na samym końcu, gdy wszystko będzie wiadome dodawałbym testy.

Nie wiem co bym mógł dodać jeszcze do tego co powiedzieli przedmówcy. Sytuacja nie wydaje się wcale aż taka dziwna jak może się wydawać w na pierwszy rzut oka. Pracowałem kiedyś w firmie gdzie wieloktornie była sytuacja że najpierw kupili wiele blackboxów, a potem stwierdzili że licencja na kolejne lata jest za droga i przepisywali wszystko tak jak potrzebowali sami. Tylko tam wyjście musiało być w stuprocentach równe temu co zwracał blackbox.

Co do testów jednostkowych mojego podejścia by to nie zmieniło:

1. Dalej ich nie lubię i preferuję integracyjne (jesli nie powoduje to spowolnień wykonywania testów).
2. Używam testów jednostkowych tam gdzie jest więcej logiki/algorytmów. Jak system jest w 75% crudem to dużej ilości kodu nie trzeba testować jednostkowo bo integracyjne już to pokryły