Wdrożenie testów jednostkowych w firmie, która tego nie robi

Kierownik ds. Rozwoju oprogramowania w mojej firmie właśnie „zrezygnował” (tj. Został zwolniony) i teraz staramy się usprawnić praktyki programistyczne w naszej firmie. Chcemy wdrożyć testy jednostkowe we wszystkich programach tworzonych odtąd.

Informacje zwrotne od twórców są następujące:

• Wiemy, że testowanie jest cenne
• Ale zawsze zmieniasz specyfikacje, więc byłoby to stratą czasu
• A twoje terminy są tak napięte, że i tak nie mamy wystarczająco dużo czasu na testy

Informacje zwrotne od dyrektora generalnego są następujące:

• Chciałbym, aby nasza firma przeprowadziła automatyczne testy, ale nie wiem, jak to zrobić
• Nie mamy czasu na pisanie dużych dokumentów specyfikacji

W jaki sposób programiści uzyskują teraz specyfikacje? Słowo ustne lub slajd PowerPoint. To oczywiście duży problem. Moja propozycja jest następująca:

• Dajmy także programistom zestaw danych testowych i testów jednostkowych
• To jest specyfikacja. Zarządzanie musi być jasne i ilościowe, co chce.
• Deweloperzy mogą umieścić to, co według nich jest potrzebne i nie musi być objęte testami

Cóż, jeśli kiedykolwiek byłeś w firmie, która była w takiej sytuacji, jak rozwiązałeś problem? Czy to podejście wydaje się rozsądne?

Wygląda na to, że mieszasz dwa różne rodzaje testów: testy jednostkowe i testy systemu / akceptacji . Te pierwsze działają na niższym poziomie, testując małe fragmenty kodu (zwykle indywidualne metody), które zwykle znajdują się głęboko w programie, niewidoczne bezpośrednio dla użytkowników. Ten ostatni testuje cały program widziany przez użytkowników na znacznie wyższym poziomie szczegółowości. Zatem tylko te ostatnie mogą być oparte na dowolnej formie specyfikacji systemu.

Rozdzielenie dwóch problemów ułatwia rozpoczęcie ulepszania procesu programowania. Rozpocznij pisanie testów jednostkowych jak najszybciej , niezależnie od tego, jak oprogramowanie jest (nie) określone na wysokim poziomie. Za każdym razem, gdy programista tworzy lub zmienia metodę, robi coś konkretnego, co może (i powinno) być testowane jednostkowo. Z mojego doświadczenia wynika, że ​​nawet zmieniające się wymagania wysokiego poziomu zazwyczaj nie wpływają dramatycznie na te bloki kodu niższego poziomu: kod wymaga głównie zmiany układu, a nie wyrzucenia lub przepisania całkowicie. W rezultacie większość istniejących testów jednostkowych będzie działać poprawnie.

Jednym z ważnych warunków włączenia testów jednostkowych jest: kierownictwo nie powinno ustalać ostatecznych terminów, lecz zamiast tego powinno opierać się na szacunkach pracy programistów (którzy z kolei powinni uwzględnić w swoich szacunkach czas potrzebny na napisanie odpowiednich testów jednostkowych). Lub, jeśli termin jest ustalony, zakres dostawy powinien być do negocjacji. Żadne (błędne) zarządzanie nie może zmienić fundamentalnej prawdy, że dana liczba programistów może dostarczyć tylko pewną ilość dobrej jakości pracy w danym czasie.

Równolegle rozpocznij dyskusję na temat najlepszego sposobu wyjaśnienia i udokumentowania wymagań i przekształcenia ich w testy akceptacyjne wysokiego poziomu. Jest to dłuższy proces sukcesywnego doskonalenia, który może zająć lata, aby osiągnąć lepszy, stabilny stan w całej organizacji. Jedno wydaje się dość pewne z twojego opisu: próba naprawienia ciągle zmieniających się wymagań przez pisanie dużych dokumentów specyfikacji po prostu nie zadziała . Zamiast tego zaleca się przejście do bardziej zwinnego podejścia, z częstymi wydaniami oprogramowania i demonstracjami dla użytkowników oraz wieloma dyskusjami na temat tego, czego naprawdę chcą. Użytkownik ma prawo w dowolnym momencie zmienić zdanie na temat wymagań - każda zmiana ma jednak swój koszt (czas i pieniądze). Programiści mogą oszacować koszt każdego żądania zmiany, co z kolei umożliwia użytkownikowi / właścicielowi produktu podejmowanie świadomych decyzji. „Z pewnością ta zmiana funkcji byłaby miła ... ale jeśli opóźni ona wydanie innej ważnej funkcji i kosztuje tak dużo, odłóżmy ją na razie do zaległości”.

Skłonienie użytkowników do zdefiniowania przypadków testowych akceptacji i utworzenia danych testowych to świetny sposób na ich większe zaangażowanie i budowanie wzajemnego zaufania między użytkownikami a programistami. Zmusza to obie strony do skoncentrowania się na konkretnych, mierzalnych, testowalnych kryteriach akceptacji i do przemyślenia przypadków użycia bardziej szczegółowo niż typowo. W rezultacie użytkownicy mogą sprawdzić bieżący stan rozwoju z pierwszej ręki przy każdym wydaniu, a programiści otrzymują bardziej konkretne, namacalne informacje zwrotne na temat stanu projektu. Należy jednak pamiętać, że wymaga to większego zaangażowania użytkowników i nowych sposobów działania, co może być trudne do zaakceptowania i nauki.

Moje doświadczenie z przejściem

Przez wiele lat nie rozumiałem, że nie mam wystarczająco dużo czasu na napisanie testów jednostkowych dla mojego kodu. Kiedy pisałem testy, były rozdęte, ciężkie rzeczy, które tylko zachęciły mnie do myślenia, że ​​powinienem pisać testy jednostkowe tylko wtedy, gdy wiedziałem, że są potrzebne.

Ostatnio zachęciłem mnie do korzystania z Test Driven Development i uznałem, że jest to kompletna rewelacja. Jestem teraz głęboko przekonany, że nie mam czasu, aby nie pisać testów jednostkowych .

Z mojego doświadczenia wynika, że ​​rozwijając się z myślą o testowaniu, otrzymujesz czystsze interfejsy, bardziej skoncentrowane klasy i moduły oraz ogólnie bardziej SOLIDNY , testowalny kod.

Za każdym razem, gdy pracuję ze starszym kodem, który nie ma testów jednostkowych i muszę coś ręcznie przetestować, ciągle myślę „byłoby o wiele szybciej, gdyby ten kod miał już testy jednostkowe”. Za każdym razem, gdy próbuję dodać funkcjonalność testu jednostkowego do kodu z wysokim sprzężeniem, ciągle myślę „byłoby to o wiele łatwiejsze, gdyby zostało napisane w sposób oddzielony”.

Porównywanie i kontrastowanie dwóch stacji eksperymentalnych, które popieram. Jeden istnieje już od jakiegoś czasu i ma dużo starszego kodu, a drugi jest stosunkowo nowy.

Dodając funkcjonalność do starego laboratorium, często chodzi o to, aby dostać się do laboratorium i spędzić wiele godzin pracując nad implikacjami potrzebnej funkcjonalności i jak mogę dodać tę funkcjonalność bez wpływu na żadną inną funkcjonalność. Kod po prostu nie jest skonfigurowany do testowania w trybie off-line, więc prawie wszystko musi być opracowane online. Gdybym spróbował opracować off-line, skończyłbym z większą ilością fałszywych obiektów, niż byłoby to uzasadnione.

W nowszym laboratorium zwykle mogę dodać funkcjonalność, rozwijając ją offline przy biurku, kpiąc sobie tylko z tych rzeczy, które są natychmiast potrzebne, a następnie spędzając tylko krótki czas w laboratorium, rozwiązując wszelkie pozostałe problemy, które nie zostały usunięte -linia.

Moja rada

Wygląda na to, że dobrze zacząłeś. Za każdym razem, gdy wprowadzasz duże zmiany w procesie programowania, musisz upewnić się, że wszyscy są zaangażowani w podejmowanie tej decyzji, a najlepiej, że większość ludzi się na to zdecydowała. Z twojego pytania wynika, że ​​masz rację. Jeśli ludzie nie mają entuzjazmu do tego pomysłu, skazany jest albo na niepowodzenie, albo na generowanie złej woli.

O ile nie możesz przedstawić przekonującego uzasadnienia biznesowego, nie zaleciłbym gruntownej implementacji testów jednostkowych i specyfikacji dla całego systemu. Jak wspomniałem powyżej, jeśli system nie jest zaprojektowany z myślą o testowaniu, napisanie testów automatycznych może być bardzo trudne.

Zamiast tego poleciłbym zacząć od małego i zastosować zasadę harcerza :

Zawsze zostawiaj kemping czystszy, niż go znalazłeś.

Jeśli podczas wdrażania czegoś na tej podstawie kodu można zidentyfikować konkretne testy wymagane do przetestowania istniejącego zachowania i przejścia ze starego na nowe, to zarówno udokumentowano zmianę specyfikacji, jak i rozpoczęto wdrażanie testów jednostek dla Twój system.

Moduły, których nie dotykasz, nie przechodzą testów jednostkowych, ale jeśli ich nie dotykasz, to prawdopodobnie dlatego, że są już dokładnie przetestowane w użyciu i nie wymagają żadnych zmian lub nigdy nie są używane.

To, czego chcesz uniknąć, to marnowanie całego ciężaru prac programistycznych na pisanie, które nigdy nie będą potrzebne ( YAGNI działa tak samo dobrze dla kodu testowego, jak i kodu produkcyjnego * 8 '), nigdy nie będzie ponownie używane i demoralizujące ludzi do myśląc, że testy są bezużyteczne.

streszczenie

Zacznij od małego, stopniowo buduj zaufanie do testów i zyskaj wartość biznesową dzięki opracowywaniu testów, kiedy i gdzie przynoszą one największe korzyści Twojemu zespołowi.

Pierwszą rzeczą do zrobienia jest skoncentrowanie się nie na testowaniu, ale na poprawnym wykonaniu całego procesu. Nie ma sensu niczego testować, jeśli nie w pełni rozumiesz, co to ma zrobić!

Więc .. najpierw specyfikacje i udokumentowane specyfikacje, które się nie zmieniają (cóż, nie od razu). Musisz spojrzeć na ich wykonanie. Polecam stronę internetową, na której użytkownicy mogą przesyłać specyfikacje lub wpisywać je bezpośrednio. Możesz również połączyć to ze śledzeniem błędów i przewodnikiem na temat postępów projektu.

Są szanse, że to wszystko, czego naprawdę potrzebujesz. Możesz dodać testy jednostkowe do tego wewnętrznie, a kierownictwo nigdy nie musi wiedzieć, że programiści przeprowadzają testy jednostkowe. W pewnym sensie tak właśnie powinno być.

Nadal będziesz musiał przeprowadzić testy systemu, ale to również można połączyć ze stroną zarządzania projektem. Po wypuszczeniu zespół testowy (nawet jeśli jest to kolejny szczęśliwy programista w rotacji) może zaktualizować go za pomocą testów, których użyli, aby sprawdzić, czy wszystko wisi razem.

Szczerze mówiąc, nie sądzę, żeby to się zmieniło z dnia na dzień, jeśli przyzwyczaiłeś się do specyfikacji „ustnych”, bitwa prawie całkowicie zmieni to zachowanie - i uzyskasz opór. Użytkownik (lub licencjat, premier lub ktokolwiek), który jest przyzwyczajony do mówienia „po prostu zrób to x” i teraz musi to wszystko napisać, nie zareaguje dobrze, są szanse, że napiszą niejasne dokumenty, a następnie je wyjaśnią z aktualizacjami ustnymi. Zapomnij o testowaniu jednostkowym i zacznij od dużego problemu związanego z cyklem rozwojowym.

Pierwszy problem: aby „dać programistom zestaw danych testowych i testów jednostkowych”, musisz najpierw napisać te testy jednostkowe, co jest zadaniem programistów. Testy jednostkowe również nie zastępują specyfikacji: specyfikacja ma mieć poziom abstrakcji wyższy niż testy jednostkowe.

Drugi problem: wydaje się, że chcesz uzyskać maksymalny zasięg testu jednostkowego. W takim przypadku napisanie testów i kodu w kontekście, w którym wymagania ciągle się zmieniają, będzie kosztowało zbyt wiele czasu i pieniędzy. Zamiast tego zdecyduj, które części kodu są krytyczne, i testuj tylko te części. W wielu przypadkach zmieniające się wymagania nie wpływają na krytyczne części produktu. Klient (lub dyrektor generalny lub jakikolwiek inny) zazwyczaj prosi o przesunięcie tego panelu w prawo lub zmianę koloru tego tytułu z czerwonego na zielony: rzeczy, na których nikt nie dba i które nie wymagają intensywnych testów. Z drugiej strony klient nigdy nie poprosi o zmianę algorytmu skrótu z SHA512 na SHA256 lub zmianę sposobu przechowywania sesji, podczas gdy te części będą wymagały najwięcej testów.