Zepsute stare / starsze testy jednostkowe

Pracuję dla dużej firmy i jestem odpowiedzialny za dużą aplikację Java z tysiącami testów Junit. Od kiedy przeniosłem się do tej roli, przeprowadzono 200–300 zepsutych testów (prawdopodobnie zepsutych przez lata). Testy są stare i kruche i stanowią bałagan zależności od spaghetti, które zwykle kończą się danymi na żywo w piaskownicy.

Moim celem jest zaliczenie testów w 100%, abyśmy mogli przerwać niepowodzenia testów jednostkowych, ale nie mogę tego zrobić, dopóki nie rozwiążę zepsutych testów. Mam bardzo mały budżet, ponieważ budżet na konserwację przeznaczony jest głównie na wsparcie, ale mój zespół zidentyfikował i naprawił nisko zawieszone testy owoców (głównie problemy z konfiguracją / zasobami lokalnymi) i jesteśmy na poziomie 30-40 naprawdę brzydkich testów.

Jakie są opinie na temat najlepszych praktyk? Nie sądzę, aby testy były cenne, ale nie wiem też, co testują ani dlaczego nie działają bez wkopania się, co wymaga czasu i pieniędzy, których prawdopodobnie nie mamy.

Myślę, że powinniśmy udokumentować statusy zepsutych testów za pomocą wszystkiego, co wiemy, a następnie całkowicie usunąć lub zignorować zepsute testy i wprowadzić element błędu / pracy o niższym priorytecie, aby je zbadać i naprawić. Będziemy wtedy na 100% i zaczniemy czerpać rzeczywistą wartość z innych testów, a jeśli mamy nadzwyczajną konserwację / refaktoryzację, będziemy mogli je ponownie odebrać.

Jakie byłoby najlepsze podejście?

Edycja: Myślę, że jest to pytanie inne niż to, ponieważ mam wyraźny kierunek testów, które powinniśmy pisać w przyszłości, ale odziedziczyłem starsze testy, które należy rozwiązać, zanim duży obecny zestaw testów stanie się znaczący.

Chciałbym najpierw wyłączyć testy, które zawodzą i zawsze mają błędy.

Spraw, by test się nie powiódł.

Podczas dochodzenia możesz zapytać o nich ludzi, którzy byli w Twojej firmie dłużej, może być na nich dużo wiedzy plemiennej, którą możesz udokumentować / schwytać. Może z twoich logów VCS. „Och, ten test zawsze kończył się niepowodzeniem od czasu uaktualnienia do X” lub inne informacje mogą być przydatne.

Po zapoznaniu się z testowaną funkcjonalnością możesz określić:

• Czy zależy nam na tym, aby to sprawdzić?
• Jak ważne jest to do przetestowania

A następnie utwórz listę priorytetów.

Prawdopodobnie nic na tej liście nie jest wystarczająco ważne, aby uzyskać więcej czasu później, ponieważ jest ignorowane od lat. Więc nie spędziłbym zbyt wiele czasu / zasobów na dokumentowaniu i analizowaniu wszystkich tych zepsutych testów.

Zrobiłbym następujące:

1. Spróbuj dokładnie określić, co nieudane testy próbują sprawdzić.

2. Triage - jeśli niektóre testy próbują przetestować nieistotne rzeczy, takie jak (stary) stan świata, usuń je. Jeśli zdasz sobie sprawę, że niektóre z nich próbują zweryfikować coś ważnego, spróbuj ustalić, czy testy te działają poprawnie. Jeśli testują niepoprawnie, spraw, by przetestowały poprawnie.

3. Napraw cokolwiek złego w kodzie produkcyjnym, gdy masz dobre testy.

Pamiętaj, księgowość, każdy wiersz kodu jest zobowiązaniem, ale może być nieprawidłowo wyceniony jako składnik aktywów. deleteKlucz może stworzyć wiele wartości dla firmy.

200-300 zepsutych testów (prawdopodobnie zepsutych przez lata).

Auć! Raz spotkałem się z podobną sytuacją, ale z 7 testami, które zakończyły się niepowodzeniem, gdy zespół zaczął ignorować fakt, że zawiodły one od miesięcy z powodu mentalności „zawsze chrupiącej”.

Moim celem jest zaliczenie testów w 100%, abyśmy mogli przerwać niepowodzenia testów jednostkowych, ale nie mogę tego zrobić, dopóki nie rozwiążę zepsutych testów.

Miałem obsesję na punkcie podobnego celu, mimo że byłem młodszym programistą w zespole, ponieważ zauważyłem stos, w którym więcej testów nie powiodło się w ciągu miesięcy. Chciałem, abyśmy zamienili je z „ostrzeżeń” na błędy kompilacji (być może nieco obrzydliwe dla reszty zespołu).

Myślę, że powinniśmy udokumentować statusy zepsutych testów za pomocą wszystkiego, co wiemy, a następnie całkowicie usunąć lub zignorować zepsute testy i wprowadzić element błędu / pracy o niższym priorytecie, aby je zbadać i naprawić. Będziemy wtedy na 100% i zaczniemy czerpać rzeczywistą wartość z innych testów, a jeśli mamy nadzwyczajną konserwację / refaktoryzację, będziemy mogli je ponownie odebrać.

To też są moje myśli. Możesz tymczasowo wyłączyć wszystkie te wadliwe testy, powoli je odwiedzać i naprawiać z czasem. Ważne jest zaplanowanie tych poprawek, jeśli uważasz je za naprawdę ważne, nawet jeśli mają niski priorytet, ponieważ takie przedmioty łatwo po prostu się nie naprawiają. Priorytetem jest dla mnie upewnienie się, że nie zostaną wprowadzone żadne nowe testy, które zawiodą.

Jak każde ostrzeżenie, jeśli nie złamią kompilacji, zwykle gromadzą się szybko. Zakłada się, że jest to rodzaj dynamiki zespołu, w którym nawyk ignorowania ostrzeżeń (w tym przypadku nieudanych testów) może szybko doprowadzić do wprowadzenia większej liczby ostrzeżeń i zmniejszyć pokusę, by ostrzeżenia te były zerowe.

Bardzo sumienny zespół może nie cierpieć z powodu tych problemów i unikać wprowadzania nowych ostrzeżeń (nowych błędów w testach), ale zdecydowanie bezpieczniej jest przejść nieco dalej i stosować strategię zapobiegania, zamieniając je w błędy, które należy naprawić przed proces scalania.

Więc moja sugestia jest taka sama jak twoja (choć tylko silna opinia - być może może to w jakiś sposób poprzeć metrykami i bardziej naukową odpowiedzią). Wyłącz te stare testy i umieść je w harmonogramie, aby je ostatecznie naprawić. Pierwszym priorytetem jest upewnienie się, że ten problem nie narasta i zacznie się pogarszać, upewniając się, że testy, które obecnie się powiodą, nie zostaną ostatecznie zignorowane, jeśli zaczną się nie powieść.

W pewnym sensie masz szczęście. Lepiej mieć testy, które zawodzą i nie powinny (dają ostrzeżenie przynajmniej, że coś jest nie tak), niż testy, które przechodzą i nie powinny (co daje fałszywe poczucie bezpieczeństwa).
Oczywiście, jeśli masz ten pierwszy, jest całkiem prawdopodobne, że masz również ten drugi (więc testy zaliczają się, ale powinny zawieść).

Jak już wspomniano, na razie wyłącz te nieudane testy, ale niech wydrukują komunikat w dzienniku testów jako stałe przypomnienie o nich.
Ale zdecydowanie powinieneś znaleźć zasoby do przejrzenia całego zestawu testów, aby znaleźć i usunąć testy, które pomyślnie i nie powinny, ponieważ każdy z nich oznacza błąd w kodzie, którego obecnie nie wykrywasz cykle testowe.

Używając tej ciemnej chmury wiszącej nad bazą kodu, możesz być w stanie uzyskać budżet na pełną recenzję swoich testów, jeśli dobrze to rozegrasz i nie powiesz im tylko, że uważasz, że niektóre testy powinny zostać przejrzane, ponieważ wydają się zawodzą, gdy nie powinny, ale nie ufasz, że twoje testy poprawnie wykrywają błędy w kodzie, że zestawowi testów nie można ufać, że wykona swoje zadanie.
Kiedy robiłem to w poprzedniej firmie, pracowałem nad taką recenzją, która wykazała, że ​​setki testów zostały napisane z nieprawidłowymi założeniami co do tego, co powinien zrobić kod, co prowadzi do tego, że kod (który został napisany przy użyciu tych samych błędnych założeń) przeszedł testy, gdy naprawdę nie powinno. Naprawienie tego problemu rozwiązało wiele nieprzyjemnych błędów w rogach, które (choć nie były krytyczne) mogły spowodować uszkodzenie niektórych ważnych systemów.

Niepowodzenie testu jednostkowego powinno spowodować uszkodzenie kompilacji. Dobrze, że udało ci się go zrealizować i wyznaczyć ten cel. Ludzki umysł nie może zignorować niczego bardziej kompletnie niż źródła trwałego fałszywego alarmu .

Odrzuć te testy i nie oglądaj się za siebie. Jeśli od lat zawodzą i nie zostały do ​​tej pory usunięte, nie są priorytetem.

Jeśli chodzi o wiedzę plemienną, jeśli ludzie z wiedzą plemienną nadal są w pobliżu, powinni już naprawić nieudane testy. Jeśli nie, to znowu nie są one priorytetem.

Jeśli nie ma wiedzy plemiennej, ty i twój zespół musicie przejąć logikę. Nieudane testy mogą być bardziej mylące niż pomocne - świat mógł się ruszyć.

Twórz nowe testy, które są odpowiednie i zacznij pisać świetny kod.