Co możesz zrobić z jakością istniejących testów integracji i testów jednostkowych będąc nowym facetem w zespole?

Powtarzającym się tematem, który spotkałem w mojej karierze, jest bycie nowym programistą w zespole i szybkie nieodłączne nieufność do istniejących testów jednostek i testów integracyjnych.

Podczas rozmowy kierownictwo informuje Cię, że „zdecydowanie wspierają testy jednostkowe” i otwarcie to zachęcają. Tak, ale wszystko w samych testach jest po prostu złe. Podobnie jak fakt, że twierdzą oni, że obejmują 100% pokrycia, gdy istnieje 100% pokrycia testem integracji, ale mniej niż 10% powtarzalnego pokrycia testem jednostkowym. Kilka innych problemów, które znalazłem:

1. Brak wyraźnego wskazania między tym, co jest testem jednostkowym, a tym, co jest testem integracyjnym. Testy jednostkowe i integracyjne są mieszane razem w tej samej klasie.

2. Testy integracyjne, w których nie zgłoszono jawnych zależności od bardzo konkretnych danych dynamicznych w bazie danych określonego środowiska.

3. Nietransakcyjne testy integracyjne, w zasadzie testy, które mogą, ale nie muszą, zadawać sobie trud czyszczenia po sobie, czasem wymagając ręcznego „czyszczenia” bazy danych, aby test był powtarzalny.

4. Żadnego kpiny, a kod aplikacji wymaga gruntownego przeglądu, aby kpina była możliwa. Innymi słowy, projektuj bez testowania.

5. Brak jasnych konwencji nazewnictwa pozwalających szybko spojrzeć na nazwę testu i z grubsza określić, jakie testy są wykonywane.

To wszystko nie oznacza, że ​​WSZYSTKIE testy są bezużyteczne lub złe, znaczna ich część jest całkiem dobra i warta zachowania, ale czasami wydaje się, że płukanie złota jest czasem. Celowo unikałbym uruchamiania testów tylko dlatego, że bałam się zepsuć bazę danych dla moich przypadków testowych czarnej skrzynki.

Zasadniczo dało mi to wewnętrzną nieufność do testów jednostkowych i integracyjnych, których osobiście nie napisałem ani nie oceniłem w żaden sposób. Na pewnym poziomie, jeśli nie wierzysz w jakość swojego zestawu testów, to naprawdę nie przynosi żadnej wartości zespołowi ani projektowi.

Co robisz, gdy znajdziesz się w takiej sytuacji? Jaki według ciebie najlepszy plan ataku to poradzenie sobie z czymś takim?

Czy wszystkie testy powinny zostać zrefaktoryzowane w ramach ogromnego wysiłku obejmującego różne wersje? Czy powinieneś po prostu zrezygnować z pomysłu, że ten starszy projekt może być objęty jednodniowym testem jednostkowym?

Przede wszystkim, jak napisali już inni plakaty, powinieneś być zadowolony, że testy jednostkowe / integracyjne są zrozumiałe (nie technicznie, to znaczy powód, dla którego należy to zrobić, są zrozumiane) i popchnięte przez kierownictwo.

Zanim zaczniesz robić wszystko, powinieneś ujawnić problemy kierownictwu, dlaczego coś należy zrobić i to bardzo dyplomatycznie, aby nie myśleli, że uważasz się za najlepszego programistę na świecie (nawet jeśli jesteś! :-). Może powiedzą ci, że aplikacja zostanie zastąpiona czymś zupełnie nowym, a jeśli tak, to po co. A może zdadzą sobie sprawę, że byłoby miło i przyspieszą fazę testowania przed każdym wydaniem. I bądźcie dyplomatyczni wobec kolegów z drużyny , może istnieć milion powodów, dla których tak jest i nie ma po prostu powodu, by szukać winowajcy.

Lepszym pomysłem byłoby spróbowanie z nimi porozmawiać, aby mogli wziąć udział w wysiłku, a ty będziesz miał mniejsze szanse na pojawienie się jako bystry dupek, byłoby bardziej „my” niż „ja”.

Teraz ustal priorytety tego, co chcesz zrobić. Priorytetyzuj zadania, zawsze wiedząc, że Twoim pierwszym priorytetem będzie zawsze bieżące zadanie projektu ... Jeśli chodzi o problem z testem, oto, co zrobiłbym w trzech fazach:

1. Jak odróżnić testy jednostkowe od testów integracyjnych? Mogą obowiązywać następujące rozwiązania, które nie są wyłączne:

   • Refaktoryzuj nazwę metody przypadku testowego (nie klasy, ponieważ właściwym zachowaniem jest, aby przypadek testowy miał tę samą nazwę co klasa testowana)
   • Utwórz dwie adnotacje, jedną o nazwie „UnitTest”, a drugą „IntegrationTest”. Adnotacji tych można używać w klasach i metodach. Jeśli cała klasa składa się z testów jednostkowych lub integracyjnych, możesz oznaczyć klasę odpowiednią adnotacją. Jeśli nie, możesz oznaczyć każdą metodę odpowiednią adnotacją. Te adnotacje mogą być również przydatne do dynamicznego wstrzykiwania urządzeń przed uruchomieniem testów (faza 3)

2. Dla każdego testu integracji wypisz, jaki jest „zbiór danych”, który powinien znajdować się w bazie danych na początku każdego testu, a co powinien zostać usunięty na końcu (np. Tabela X, potrzebuje rekordu z „id” ustaw na „1”, a „name” na „foo” itp.). Pamiętaj, że to, co usuwasz, może być większe / mniejsze niż na początku, ponieważ sam kod może odpowiednio dodawać / usuwać obiekty z warstwy trwałości. Najprawdopodobniej szybko zauważysz, że kilka z tych przypadków testowych potrzebuje tego samego zestawu danych lub części tego samego zestawu danych.

3. Pierwsze dwie fazy można wykonać stosunkowo szybko ... w porównaniu z resztą. Teraz, gdy masz już zestaw danych, możesz użyć urządzeń do tworzenia zestawu danych dla każdego przypadku testowego, który go potrzebuje. Ale będzie to kosztowało trochę czasu ... Więc możesz to zrobić, zobaczyć, ile to kosztuje i oszacować, ile więcej czasu potrzebujesz na zrobienie wszystkiego. Możesz również użyć tego testu, aby pokazać kolegom, co zrobiłeś i dlaczego życie jest o wiele łatwiejsze, gdy nie musisz mieć bazy danych w określonym stanie, aby wykonać testy.

Możesz zauważyć, że etap 1, 2 i 3 można wykonać na jednej klasie testowej, jeśli szybko chcesz pokazać współpracownikom / kierownictwu, jak można to zrobić. Byłoby to również przydatne, jak napisał Péter Török, aby od razu pokazać „dobrą drogę” swoim kolegom z zespołu, aby przestali produkować zły kod. Myślę jednak, że resztę fazy 2, identyfikującą cały zestaw danych testowych, najlepiej wykonać w jednym dużym kroku.

Jeśli chodzi o API / technologię stojącą za tym wszystkim, wydaje się, że znasz ten temat.

Mam nadzieję, że trochę pomogło.

Uwaga: w mojej propozycji zakładam, że kodujesz w Javie / C #, gdzie wiem, że adnotacje są możliwe, a AOP jest możliwe. Jestem pewien, że jest to również możliwe w innych językach, ale nie będę pisać o czymś, czego nie wiem.

Nie będziesz w stanie naprawić wszystkich testów razem. Myślę, że powinieneś skupić się na poprawie słów w porównaniu z przeglądem . Ani zarządcy, ani programiści nie zgodzą się na remont, ale jeśli wykażesz, że istnieje sposób na ulepszenie rzeczy bez negatywnego wpływu na projekt, będą bardziej skłonni do słuchania.

Po pierwsze, nie można „naprawić” ani zrefaktoryzować istniejącego kodu, jeśli nie ma się pokrycia testami jakości, więc najpierw skupię się na naprawie infrastruktury testowej.

Zrób listę rzeczy, które wymagają ulepszenia, i spróbuj ustalić ich priorytety. Myślę, że zdolność do uruchamiania testów niezależnie i pojedynczo (więc nie wpływają one na siebie nawzajem) oraz oddzielenie testów jednostkowych i integracyjnych to jedne z pierwszych rzeczy, nad którymi należy popracować. Musisz ułatwić tobie i innym podejmowanie właściwych kroków.

Jeśli chodzi o kod aplikacji ... Nie będzie można przeprowadzić pełnego przeglądu architektury aplikacji, aby można ją było lepiej przetestować. Zamiast tego, kiedy wstawiasz nowy kod, spróbuj zastosować zasady, które ułatwiają test jednostkowy (np. Wstrzykiwanie zależności). Możesz pomyśleć, że nie jest to wystarczająco duża zmiana, ale zadziwiające, jak szybko deweloperzy łapią, jeśli widzą korzyści. Musi być ktoś, kto zacznie wprowadzać zmiany na lepsze.

Porozmawiaj ze swoim zespołem i zachęć ich do wpisowego. Jedną z najważniejszych rzeczy, które możesz zrobić, to postępować zgodnie z „ Zwiadowcą ” i wprowadzić niewielkie ulepszenia, aby opuścić klasę lub test w lepszej formie, niż ją znalazłeś . Jeśli cały zespół zastosuje tę zasadę, będzie znacznie lepiej.

Po chwili będziesz mieć dużo kodu, który jest zgodny z dobrymi zasadami i obszarami aplikacji, które są w złym stanie. W tym momencie masz podstawowe pojęcie o tym, co jest dobre, a zespół może zdecydować, czy warto zrobić większy refaktor dla starszych materiałów, czy może po prostu żyć tak, jak jest.

Muszę przyznać, że wziąłbym to za rzadki dar, aby dostać się do projektu, w którym przeprowadzono już znaczną liczbę testów jednostkowych / integracyjnych - do tej pory nigdy nie miałem takiego szczęścia w życiu. Nawet jeśli nie wszystkie z nich działają tak, jak powinny, włożono w to już wiele wysiłku, a nawet jeśli zespół i kierownictwo nie zawsze przestrzegają najlepszych praktyk, nadal są zaangażowani w sprawę, więc nie musisz tracić czasu na kłótnie, dlaczego warto pisać testy jednostkowe.

Jednak testy, które opisujesz, mogą rzeczywiście nieco poprawić. Ale trzeba być ostrożnym z tonu przy omawianiu problemów ze swojej drużyny . Jeśli zaczniesz od stwierdzenia, że „wszystko w samych testach jest po prostu błędne” , możesz bardzo szybko skończyć z wyobcowaniem reszty zespołu. Zamiast tego powinieneś skupić się na tym, jak poprawić obecny stan rzeczy, który - muszę powtórzyć - jest nadal znacznie lepszy niż średnia według mojego dotychczasowego doświadczenia.

IMO twoim pierwszym celem powinno być powstrzymanie zespołu przed produkcją kolejnych złych testów . Zacznij więc od wykazania korzyści z każdego konkretnego ulepszenia swoim kolegom z drużyny. Jeśli zauważą przydatność określonej techniki - czy to do zmniejszania zależności zewnętrznych, przywracania pierwotnego stanu po każdym teście, czy oddzielania testów jednostkowych i integracyjnych - zaczną je stosować. To samo w sobie powoli, ale z pewnością poprawi ogólną jakość bazy testowej na dłuższą metę (jeśli masz teraz 1000 złych przypadków testowych, a zespół przygotuje 1000 dobrych testów do przyszłego roku, zmniejszysz odsetek złych testów od 100% do 50%). Po zabezpieczeniu możesz zdecydować o refaktoryzacji istniejących testów na podstawie indywidualnych przypadków. Ponownie, małe ulepszenia z czasem będą stanowić duże zmiany.

Na marginesie, z tonu twojego postu czuję, że możesz być w miejscu, w którym ja też byłem: brak zaufania do pracy wykonanej przez innych, niemożność przekazania zadań komukolwiek, obawiając się, że ich praca nie zależy od ciebie własne standardy jakości. Z mojego doświadczenia wynika, że ​​nie jest to dobre miejsce, ponieważ na dłuższą metę może łatwo doprowadzić do osobistych konfliktów i wypalenia zawodowego. Nie możesz zrobić wszystkiego sam, musisz współpracować z resztą zespołu. Możesz odnieść sukces tylko razem.

Pracuj nad niezależnością testu. Jeśli test X zmodyfikuje testową bazę danych w taki sposób, że test Y nie powiedzie się, zmień test Y. W tym małym scenariuszu należy się skupić nie na tym, że X zawalił bazę danych, ale na tym, że Y ma nieodpowiednie zależności. Usuń te zależności (usuwając bazę danych, restrukturyzując test lub inicjując bazę danych do stanu, w którym Y przejdzie), a teraz masz jeszcze jeden niezależny, działający test. To postęp (prawdopodobnie nie byłoby „naprawienia” X, aby nie zepsuć bazy danych).

Bądź cierpliwy i pełen szacunku, najlepiej jak potrafisz, wobec ludzi, z którymi pracujesz, pomimo bałaganu, który stworzyli. Starają się postępować właściwie, najprawdopodobniej; miej to na uwadze i pomóż im to zrobić.

Dobrą rzeczą w byciu nowym w zespole jest to, że masz „świeże” podejście do rzeczy. Złą stroną może być to, że inni mogą mieć trudności z uwierzeniem.

Nie rób listy rzeczy do zrobienia. Ale wybierz JEDNĄ rzecz, która wydaje się pilna i na którą inni najprawdopodobniej odpowiedzą i zaproponują rozwiązanie. Jeśli to działa, świetnie, to zasugeruj inne rozwiązanie innego problemu, w oparciu o swój pierwszy sukces.

Ale powoli, jeden po drugim, i miej nadzieję, że twoje pomysły powoli „złapią” się w nowej grupie.

daj przykład, który chcesz zobaczyć, ale doceń perspektywę innego programisty w teście: jeden programista może testować pod kątem sukcesów, podczas gdy inny może testować pod kątem awarii, jeden programista napisał klasę, podczas gdy inny mógł użyć go po raz pierwszy podczas pisania testu.

istniejące testy (erm, większość) wciąż mają cel, chociaż może nie być od razu widoczne. nie polecam przeglądu i refaktoryzacji wszystkiego naraz (jest to żmudne i podatne na błędy). złe testy ostatecznie wymagają aktualizacji, przepisania lub mogą po prostu stać się przestarzałe w miarę ewolucji oprogramowania.

jeśli twoje podejście do testowania jest lepsze pod pewnymi względami, ludzie będą uczyć się z tego modelu lub poprosić cię o pomoc. będzie równowaga zasobów, ale możesz rozszerzyć w razie potrzeby, aby wesprzeć swoje testy.

ostatecznie chcesz poprawić jakość programów poprzez testy i poprawić zasięg. możesz to zrobić, kładąc większy nacisk na testowanie i dając dobry przykład - ale doceniaj perspektywy innych.

podkreślając znaczenie, możesz zmienić środowisko operacyjne testów - jednym oczywistym przykładem jest równoległe uruchamianie testów; jeśli nie jest to ponowne wysłanie, oznacza to, że znalazłeś błąd w swoim programie lub teście (win / win). Bardziej rygorystyczne środowisko testowe wymusi naprawienie i / lub przepisanie złych testów (mam nadzieję, że za drugim razem). powoli wprowadzaj takie zmiany (nie przerywaj jednocześnie połowy testów - to prawdziwy problem), zmuszając je do nauczenia się, co stanowi dobry test, a ostatecznie dobry program. wtedy, gdy ty i inni wchodzicie i modyfikujecie / naprawicie / rozszerzacie testy, zastosujcie to, czego się nauczyliście - jest to przyrostowe i masz lepsze zrozumienie kontekstu / programu w danym momencie.

Napraw je z czasem

Byłem w tej samej sytuacji. Spędziłem tylko godzinę każdego ranka, testując i naprawiając je, aż wszystkie zostały naprawione. To była średnia baza kodów i myślę, że skończyłem w 1,5 miesiąca. W testach nabrałem też pewności siebie.

Osobiście nie dbam o to, czy test jest testem jednostkowym czy testem integracyjnym, o ile jest to dobry test. Przez dobry test rozumiem, że:

• sprząta po sobie
• jest powtarzalny
• minimalizuje interakcje środowiskowe
• jest spójny

Po drodze ewangelizowałem lepszą konstrukcję testową (to znaczy, że dużo zganiłem ludzi).