Testy jednostkowe Zespół początkujący musi przeprowadzić test jednostkowy

Pracuję z nowym zespołem, który w przeszłości nie przeprowadzał ŻADNYCH testów jednostkowych. Moim celem jest, aby zespół ostatecznie zastosował TDD (Test Driven Development) jako swój naturalny proces. Ale ponieważ TDD jest tak radykalną zmianą umysłu dla zespołu testującego niejednostkowe, pomyślałem, że zacznę od pisania testów jednostkowych po kodowaniu.

Czy ktoś był w podobnej sytuacji? Jaki jest skuteczny sposób, aby zespół poczuł się komfortowo z TDD, gdy nie przeprowadzili żadnych testów jednostkowych? Czy ma to sens w kilku krokach? A może powinniśmy zanurkować i stawić czoła narastającym bólom naraz?

EDYTOWAĆ

Tylko dla wyjaśnienia, w zespole (oprócz mnie) nie ma ŻADNEJ jednostki testującej narażenie / doświadczenie. I planujemy użyć funkcji testowania jednostkowego wbudowanej w Visual Studio.

Przećwicz istniejące błędy / wady.

To naprawdę trudna sytuacja. Nigdy wcześniej nie przeszedłem do TDD z niczego, ale z mojego doświadczenia wynika, że ​​przejście od braku testów jednostkowych do proaktywnego pisania ich było podejściem „krok po kroku”.

Po pierwsze, zapewnij im wygodne testy jednostkowe i dowiedz się, czym naprawdę są i jakie są ich zalety. Dla moich zespołów najlepiej napisać testy jednostkowe dla istniejących błędów. Obecne błędy w systemach mają dwie rzeczy, których potrzebujesz, aby nauczyć ludzi, jak dobrze pisać testy jednostkowe:

1. oczekiwany warunek wstępny i późniejszy
2. wynik, który obecnie nie jest oczekiwany i narusza ten warunek wstępny / wtórny

Daje to członkom bardzo konkretne przykłady praktyki. Mogą napisać test, zanim naprawią błąd, aby się nie powiódł. Następnie mogą naprawić kod, aby go przekazać, i naprawić błąd. Gdy już sobie z tym poradzą, możesz zdobyć je do końca, aby mogli napisać testy jednostkowe bez kodu z góry, a następnie napisać nowy kod, aby zaliczyć swoje testy.

Myślę, że sztuczka polega na tym, aby dać im coś do przećwiczenia tam, gdzie istnieją jasne metody przed / po spełnieniu warunków. Jeśli wymagania dotyczące metod są niewyraźne, nawet doświadczonym osobom TDD trudno jest dokładnie wiedzieć, od czego zacząć. Zrób krok na raz, a dotrzesz na miejsce. Powodzenia!

Udało mi się przekonać całą moją firmę do przejścia na TDD. Nie było to łatwe, ale było warte wysiłku: jakość kodu podniosła się po przejściu, a teraz nikt nie wyobraża sobie powrotu do okropnych, kowbojskich czasów kodowania.

1. Wyjaśnij, wyjaśnij, wyjaśnij. Nie chcesz, aby Twój zespół pisał testy. Chcesz, aby Twój zespół chciał pisać testy. Oznacza to, że powinni oni w pełni zrozumieć, dlaczego powinni to robić, jakie są korzyści i jak to znacznie ułatwi ich pracę. Czerwony, Zielony, Refaktor , pisanie testu regresji jako dowód, że błąd został naprawiony itp. Musisz przekonać ich, że cała sprawa ma sens, zanim poprosisz ich o napisanie kodu.

2. Idź po prawdziwą rzecz (pierwsze testy, potem kod). Pisanie testów po kodzie nie ma większego sensu, ponieważ nigdy nie wiadomo, czy one faktycznie działają (a ludzie piszą błędne przypadki testowe). Moją intuicją jest to, że wysiłek, który musisz przejść od testów bez testów do testów, jest znacznie mniejszy niż to, co musisz przejść od testów od kodu do testów , więc równie dobrze możesz pominąć środkowy krok.

3. Zacznij od testów regresji. Są dość proste do zrozumienia i dają natychmiastową satysfakcję. Oczywiście zakłada to, że kod jest odpowiednio zmodularyzowany i łatwy do przetestowania. Jeśli nie, pomiń ten krok.

4. Rób kroki dla dzieci. TDD wymaga czasu, aby się przyzwyczaić i na początku może być frustrujące. Spróbuj wprowadzić testowanie w zupełnie nowym projekcie lub komponencie, idealnie: coś niezbyt ważnego. Chcesz za wszelką cenę uniknąć sytuacji, w której trzeba naprawdę szybko zrobić coś naprawdę ważnego, a programiści uważają, że przeszkadza TDD.

5. Kiedy zespół zaczyna czuć się komfortowo, wszystkie nowe funkcje powinny być napisane w sposób TDD. Zależy to od wielkości twojego projektu, ale po pewnym czasie powinieneś uzyskać całkiem dobry zasięg, z tylko niektórymi starszymi częściami projektu napisanymi w stary sposób.

6. W tym momencie zespół powinien już zrozumieć i zaakceptować TDD, a starsze (nie TDD) rzeczy należy uznać za trudne i denerwujące w pracy. Zrób to ponownie: większość ludzi zrobi to z przyjemnością.

Kilka innych ważnych punktów:

• Upewnij się, że korzystasz z najlepszych dostępnych ram testowania. Znacznie trudniej będzie przekonać ludzi do zrobienia TDD, jeśli będą musieli wchodzić w interakcję z źle napisaną biblioteką.

• Upewnij się, że testy są łatwe do uruchomienia i nie zajmują dużo czasu do zakończenia (lub oszukiwania, na przykład poprzez użycie db w pamięci do testów).

• Skonfiguruj oprogramowanie do ciągłej integracji, aby natychmiast znaleźć zepsute testy.

Jednym ze sposobów na wygodne korzystanie z TDD jest napisanie najpierw testów integracyjnych. Później przedstaw szwy testowe i prawdziwe testy jednostkowe.

Problem z pisaniem testów jednostkowych po kodowaniu polega na tym, że kod niekoniecznie musi być dobrze zaprojektowany do testowania . Konieczne może być przeprowadzenie refaktoryzacji lub przeprojektowanie, aby wprowadzić szwy testowe. Ale jak możesz bezpiecznie przebudować lub przeprojektować, jeśli nie masz żadnego pokrycia testowego ?

Testy integracyjne mogą początkowo zapewnić taki zasięg. Za każdym razem, gdy masz problem z regresją lub produkcją, napraw go w kodzie i przykryj kod testem. Gdy masz już wystarczającą siatkę bezpieczeństwa zapewnianą przez takie testy, możesz wprowadzić testy jednostkowe bardziej drobnoziarnistych, izolowanych komponentów i / lub klas swojego systemu.

TDD jest bardzo trudne do wdrożenia i nie zawsze jest najlepszą opcją dla każdego zespołu programistów. W mojej poprzedniej pracy zespół był mocno skoncentrowany na TDD. Nasz model rozwoju był całkowicie TDD przy użyciu zwinnego podejścia programistycznego. Testy przeprowadzono za pomocą testów jednostkowych Visual Studio.

Jeśli programista nie napisałby testów jednostkowych dla swojej funkcji, miałby kłopoty z przewodnikiem technicznym. Ponadto, jeśli ktoś zamelduje zepsutą kompilację lub testy jednostkowe, programista będzie musiał naprawić wszystkie problemy i dodać 1 $ do słoika z pieniędzmi zespołu.

Wystarczy dodać drobną wizualizację procesu. Wykonaj ciągłą integrację, uruchamiając automatycznie testy i sprawdzaj dostępność kodu. Wymień najbardziej kompletne przetestowane moduły na stronie startowej, którą każdy może zobaczyć. To powinno rozpocząć rywalizację drużynową.

Przeszedłem z doświadczenia bez JUnit prosto na TDD, a doświadczenie to wyraźnie pokazało wartość TDD. Stałem się tak wdzięczny za testy jednostkowe, że szybko stałem się ewangelistą

Byłem w zespołach, które nie przeprowadzały żadnych testów jednostkowych, ale zostało to wprowadzone i stało się prawie powszechne, że mam teraz kilka testów. Sugerowałbym zbadanie, jak dobrze Twój zespół rozumie podstawy testowania jednostkowego, a także jakie narzędzia chcesz tu wprowadzić?

W moim przypadku wprowadzono nUnit dla jakiegoś kodu .Net, który był połączeniem logiki biznesowej, interfejsu użytkownika i funkcji zaplecza. Sugerowałbym sprawdzenie, czy są ludzie, którzy są bardziej skłonni do tego, aby dostać się do tego bardziej niż inni, aby kilka osób w zespole je dostało i mogło rozprzestrzeniać się nieco lepiej niż druga strona, w której próbujesz zdobyć wszystkich wskoczyć na to. Dzięki temu, że niektórzy dobrze to zrobią, umożliwia to trening krzyżowy, dzięki czemu osoby, które go podniosą, mogą zostać przetestowane pod kątem tego, jak dobrze mogą uczyć go kogoś innego.

Inną kwestią jest rozważenie wprowadzenia osób posiadających większą wiedzę specjalistyczną, aby w pewnym stopniu się tym pochwalić. Chociaż prace zostały wprowadzone, gdzie pracuję, aby pokazać nam, że niektóre z nich zostały powszechnie przyjęte, a inne nie tak bardzo, ale myślę, że tak by było w większości miejsc.