Jak przekonałeś swojego kierownika, aby pozwolił ci na test jednostkowy?

Przez „użycie” mam na myśli pozwolenie na rozwój, odprawę do kontroli źródła i utrzymanie testów jednostkowych w czasie itp.

Typowe zastrzeżenia kierownictwa to:

1. Klient nie zapłacił za testy jednostkowe
2. Projekt nie przewiduje czasu na testy jednostkowe
3. Dług techniczny? Jaki dług techniczny?

Czy znasz inne zastrzeżenia? Jakie były twoje odpowiedzi?

Z góry dziękuję!

Ostatnio natknąłem się na ten problem, gdy klient był przy naszej metodyce, ale wyższe kierownictwo dowiedziało się, że programiści spędzają czas na testowaniu, a nie rozwijają się i martwią się tym - w końcu mieli do dyspozycji osoby odpowiedzialne za kontrolę jakości! Blogowałem o tym, jak sobie z tym poradziłem:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Podsumowując, porównałem nasze szacunkowe godziny z faktycznymi godzinami dla projektu, a następnie porównałem nasz wskaźnik wad z współczynnikiem wad innych zespołów. W naszym przypadku liczby te wypadły korzystnie i nie było już żadnych obaw.

Mój wniosek oparty na tym doświadczeniu jest następujący:

... najlepszym sposobem, aby przekonać każdego, że twoje podejście do robienia czegoś jest praktyczne i pragmatyczne, to zrobić to i porównać z innymi podejściami. Ludziom nie zależy na dogmatach ani na tym, dlaczego uważasz, że coś powinno być najlepszym sposobem. Tylko pokazując ludziom liczby i mierząc skuteczność swojego podejścia, możesz naprawdę pokazać, że twoje praktyki są skuteczne.

Przy innych projektach współpracowaliśmy z programistami klientów, którzy nie stworzyli testów jednostkowych ani nie przeprowadzili TDD i musieliśmy utrzymać testy, które przełamują. Jednak bardzo łatwo jest sprzedać podejście TDD tym programistom klientów, kiedy możesz im powiedzieć, co złamali w kodzie, zanim się dowiedzą!

Więc w twoim przypadku zrobiłbym to ukradkiem, jeśli to konieczne (być może jest mały obszar kodu, który możesz zacząć testować, że często się zmienia lub za który jesteś odpowiedzialny), ale pamiętaj o swoich liczbach - co to jest wysiłek na stworzenie swoich testów? Jaka jest liczba wad? Jak to się ma do innych projektów / członków zespołu?

Moim zdaniem nikt nie powinien pytać o zgodę ani przeprosić za to, że chce właściwie wykonywać swoją pracę, a każdy profesjonalny programista powinien próbować testować swój kod za pomocą testów automatycznych, tam gdzie jest to możliwe i praktyczne. Mam nadzieję, że w twoim przypadku są to obie te rzeczy. Powodzenia!

Pokaż zwrot z inwestycji (ROI)

Pisanie automatycznych testów wymaga czasu. Pewnego razu. Przeprowadzanie testów automatycznych zajmuje zero czasu, ponieważ możesz zrobić coś innego podczas ich działania.

Przykład: Ręczne testowanie funkcji X zajmuje 30 minut. Napisanie zautomatyzowanego testu zajmie 1 godzinę. Nawet jeśli nie mamy żadnych błędów, będziemy musieli przetestować cechę X dziesięć razy w trakcie projektu, gdy jej zależne warstwy i komponenty zostaną zmodyfikowane. Zautomatyzowanie testu funkcji X pozwoli nam zaoszczędzić 4 godziny w trakcie trwania projektu.

W rzeczywistości, kiedy masz błąd, automatyczne testy naprawdę się opłacają - po pierwsze, znajdują błędy wcześnie i tanio, co oszczędza czas i kłopot. Po drugie, jeśli masz trudny błąd i przechodzisz przez wiele cykli tworzenia kodu, aby go rozgryźć, czas zaoszczędzony na ręcznym testowaniu jest wyjątkowo szybki.

Firmy rozumieją, jak oszczędzać czas i pieniądze. Tak to sprzedać.

Jeśli już się z nimi spotkałeś i nie są w porządku, ale bez nich nie czujesz się komfortowo pisząc kod ... nie pytaj ponownie. Po prostu je napisz i nie melduj się.

Zarząd nie zamierza liczyć wierszy kodu, ale zobaczy, że wszystkie twoje zgłoszenia mają wyższe wskaźniki przepustowości od kontroli jakości (lub klientów) i ostatecznie zapytają, dlaczego ... to możesz być taki jak "BAM! TDD ! ”

Nie zadzierasz z projektem, procesem lub źródłem ... więc nie widzę negatywnego powodu. Szczerze mówiąc, nie widzę powodu, dla którego jest inaczej niż uruchamianie wszystkich testów ręcznego uruchamiania + wprowadzania + sprawdzania wyników.

1) Klient nie zapłacił za testy jednostkowe

Klient (myślał, że zapłacił) za działające rozwiązanie. W zależności od umowy naprawianie usterek może być opłacalne dla Twojej firmy. Jeśli jest wystarczająca blokada. Wróćmy do płacenia za działające rozwiązanie. TDD powinno pomóc w osiągnięciu tego celu.

2) Projekt nie przewiduje czasu na TDD

TDD nie trwa dłużej. Powinno to zmniejszyć ilość zbędnego lub zbędnego kodu i skoncentrować bazę kodu na tym, co sprawia, że ​​testy są udane. Wszystkie zaliczone testy, z zastrzeżeniem jakości i adekwatności testu, oznaczają, że kod został wykonany.

3) Dług techniczny? Jaki dług techniczny?

Mam wrażenie, że możesz argumentować za retrospektywnym dodaniem testów do istniejącego kodu. To najlepsza okazja na koszmar i nie przynosi oczekiwanych korzyści. Jednak dodawanie testów podczas naprawiania błędów powinno być dopuszczalne i pomagać na dłuższą metę.

I tak nie polecam pisać testów, jak sugerował Snorfus. To brzmi nieźle w teorii, ale testy jednostkowe można i zrobić zmiany w czasie. Wraz ze zmianami wymagań pojawiają się nowe funkcje, dlatego testy jednostek wymagają aktualizacji. Jeśli pracujesz w zespole, testy jednostkowe będą przestarzałe, gdy inni dodadzą funkcje / poprawki.

Zajmuję się konkretnymi punktami, o których wspominałeś, a nie podnoszeniem nowych, ponieważ istnieje swoboda, by robić postępy lub zrozumieć, dlaczego jest blokowany.

Dla każdego klienta mającego problemy produkcyjne,

1. Napisz test jednostkowy i wyślij wiadomość e-mail do kierownika, informując, że dodałeś test jednostkowy na wypadek scenariusza.

2. I powiedz mu, że ten problem nie powtórzy się w produkcji, ponieważ nasz test jednostkowy jest przeprowadzany co noc i dowiemy się, zanim kod przejdzie do produkcji, obserwując niepowodzenie testu jednostkowego.

3. Powiedz mu, że gdybyśmy mieli już test Jednostki, zanim kod trafił do produkcji, ten problem z produkcją nigdy by się nie zdarzył.

Rób to konsekwentnie i wytrwale, a wkrótce on się przekona. Menedżerom nie podoba się klient, który boryka się z problemami produkcyjnymi, i kupi pomysł na testowanie jednostkowe. Powodzenia.