Jeśli testy jednostkowe są tak świetne, dlaczego nie robi tego więcej firm? [Zamknięte]

Pierwsza prawdziwa firma programistyczna, w której pracowałem, dotyczyła testów jednostkowych (NUnit). Nie wiem, czy wtedy byliśmy prawdziwymi zwolennikami tego zagadnienia - nie mam pojęcia, jak wyglądało nasze pokrycie kodu i pisałem większość testów jednostkowych. Od tego czasu natknąłem się na kilka firm, które przeprowadzają wiele testów, ale są to testy na krzesłach: polegają na obecności osoby, mają niską powtarzalność i małą szansę na złapanie błędów. Inna postawa jest taka: to było coś, co chcieli osiągnąć „w przyszłości”; zasadniczo kiedy pieniądze spadają z nieba.

Brakuje mi testów jednostkowych - to po prostu ułatwia życie. Ale odkrywam, że kiedy szukam nowej pracy, testy jednostkowe są czymś, z czym firmy chciałyby się „zacząć” w przyszłości lub czymś, czego w ogóle nie robią (uhh, to było już od jakiegoś czasu teraz!). Powiedziałbym, że 60-75% wymagań pracy, na które patrzyłem w ciągu ostatnich 2 lat, w ogóle nie wymieniało testów jednostkowych. Przychodzi mi do głowy tylko jedna lub dwie osoby, które miały doświadczenie w testowaniu jednostkowym jako wymaganie (na stanowisko programisty średniego poziomu).

Więc pytanie brzmi, czego brakuje ? Myślę, że to sprawia, że ​​ludzie są bardziej produktywni, ale to dopiero po spędzeniu dużej ilości czasu na robieniu tego. Czy nie ma dobrych badań dotyczących oszczędności kosztów testów jednostkowych? Czy to jest rodzaj firmy, na którą patrzę?

Edycja: mimo że tytuł jest trochę zwolennikiem diabłów, uważam się za zwolennika testów jednostkowych.

Z mojego doświadczenia wynika, że ​​jest na to kilka czynników:

1. Kierownictwo tak naprawdę nie rozumie, czym tak naprawdę jest testowanie jednostkowe ani dlaczego ma dla niego rzeczywistą wartość wewnętrzną.
2. Kierownictwo jest bardziej zainteresowane szybką dostawą produktów i (nieprawidłowo) postrzega testy jednostkowe jako szkodliwe dla osiągnięcia tego celu.
3. Istnieje błędne przekonanie, że testowanie należy wyłącznie do funkcji kontroli jakości. Deweloperzy są programistami i nie mogą pisać testów.
4. Istnieje powszechne błędne przekonanie, że kierownictwo będzie musiało wydawać pieniądze na prawidłowe przeprowadzanie testów jednostkowych, mimo że narzędzia są dostępne bezpłatnie. (Oczywiście programista musi wziąć pod uwagę czas na przyspieszenie, ale nie jest to zbyteczne).
5. Odpowiedź Willa zaokrągli tę odpowiedź: Bardzo trudno jest określić wartość kodu testowego (edytuj jcollum)

Oczywiście istnieją inne czynniki, ale to jest to, na co do tej pory się natknąłem.

1) To trudne
2) To wymaga czasu
3) Bardzo trudno jest określić wartość kodu testowego

Punkt 3 jest lepki. Dobre testy jednostkowe zmniejszają liczbę błędów. Ale tak samo jak dobry kod produkcyjny. Jak określić, ile błędów nie istnieje z powodu testów jednostkowych? Nie możesz zmierzyć tego, czego nie ma. Możesz wskazać studia, ale nie pasują one dobrze do arkusza kalkulacyjnego menedżera firmy.

Łatwo jest zrzucić całą winę na „zarządzanie”. Ale czy kierownictwo naprawdę mówi ci, żebyś specjalnie nie wykonywał testów jednostkowych?

Zarządzanie generalnie nie mówi (i prawdopodobnie nie powinno) mówić Ci, jak wykonywać swoją pracę, czy jest to modularyzacja, abstrakcyjne typy danych, wzorce projektowe czy testy jednostkowe. Są to narzędzia handlowe, które stosuje odnoszący sukcesy, kompetentny inżynier oprogramowania, ale kiepski inżynier tego nie robi.

Myślę, że prawdziwa odpowiedź na twoje pytanie brzmi: testowanie jednostkowe jest naprawdę trudne, a studenci informatyki nie są do tego przygotowywani.

Jest to łatwe, gdy piszesz własną klasę ciągów. Kiedy testujesz rzeczywisty produkt, napotykasz wyzwania, o których nikt ci nie powiedział na slajdach PowerPoint:

• Interakcja z użytkownikiem. Połowa aplikacji to logika interfejsu użytkownika. Jak to przetestować w sposób zautomatyzowany, aby nie zepsuło się, jeśli przesuniesz przycisk?
• Interakcja z zewnętrznymi interfejsami API i frameworkami. Jeśli piszesz sterownik jądra systemu Windows, jak przetestujesz go jednostkowo? Czy piszesz kody pośredniczące dla każdej używanej funkcji IRP i jądra, skutecznie tworząc symulację jądra systemu operacyjnego?
• Komunikacja sieciowa to rzecz XXI wieku. Jak koordynujesz test jednostkowy składający się z kilku rozproszonych komponentów?
• Jak wybrać dobre przypadki testowe? Często widzę ludzi próbujących „robić przypadkowe rzeczy w pętli 1000 iteracji i zobaczyć, czy się zepsuje”. Kiedy to zrobisz, wysiłek jest większy niż zwroty, ważne błędy są pomijane, a testowanie jednostkowe jest porzucane.
• Jak sprawdzić, czy wymagania dotyczące wydajności są spełnione?
• Znajomość wzorców w testowaniu jest niewielka: fragmenty kodu, gotowe odpowiedzi, testy regresji to pojęcia, których większość ludzi nie zna. Ilu w Twoim miejscu pracy faktycznie czyta książkę o testach jednostkowych?

Jedyną rzeczą, za którą możemy winić kierownictwo, jest to, że specyfikacje wymagań rzadko zawierają wymagania dotyczące poziomu jakości dostarczanego produktu.

Następnym razem, gdy szef poprosi Cię o oszacowanie czasu, uwzględnij czas na napisanie testu jednostkowego i zobacz, co się stanie.

Większość testów niczego nie testuje.
Piszesz funkcję fileopen () i unittest, która kończy się niepowodzeniem, jeśli plik nie istnieje i powiedzie się, jeśli plik istnieje. Wspaniały! Czy teraz sprawdziłeś, czy działa z nazwą pliku w języku chińskim BIG5? na udziale NFS? w systemie Vista z plikiem na kluczu USB i włączoną kontrolą konta użytkownika?

Problem polega na tym, że testy jednostkowe są pisane przez tego samego programistę, który napisał funkcję, na tym samym zestawie założeń i na tym samym poziomie umiejętności. Aby testy naprawdę działały, muszą być napisane przez kogoś innego, tylko zgodnie z opublikowaną specyfikacją, bez oglądania kodu. - W większości firm samo napisanie specyfikacji byłoby przełomem!

Testy jednostkowe sprawdzają błędy w kodzie poszczególnych funkcji. Mogą pracować dla warstw dostępu do danych, bibliotek matematycznych itp., Gdzie dane wejściowe / wyjściowe są dobrze znane, a struktura wewnętrzna jest złożona, ale w wielu przypadkach są one tylko stratą czasu.
Zawodzą, gdy błędy wynikają z interakcji między różnymi częściami kodu lub z systemem operacyjnym i użytkownikiem. Problemy, takie jak ustawienia wysokiego / niskiego DPI, zepsucia okna dialogowego lub zamiana ustawienia języka obcego na znak „.” i „,” zwykle nie są znalezione.

Przeprowadzono badania dotyczące zwrotu z inwestycji w testy jednostkowe - zobacz to pytanie .

Znalazłem wielu programistów, którzy nie są zainteresowani testowaniem jednostkowym. Na początku zawsze wydaje się, że jest to dużo pracy z niewielkim zyskiem. Nikt nie chce zapisywać się do dodatkowej pracy, więc stawiają opór. Kiedy ludzie zaczynają, zwykle entuzjastycznie się tego trzymają, ale rozpoczęcie ich może być trudne.

Pomijając kwestię przyjęcia testów jednostkowych, testy jednostkowe nie zawsze są warte zachodu, chociaż generalnie myślę, że tak jest, gdy są właściwie stosowane. W testach jednostkowych nie ma nic specjalnego, co uchroni je przed podatnością na słabą konstrukcję.

Testy jednostkowe wiążą się z kosztami (tworzenie, konserwacja i uruchamianie) i są opłacalne tylko wtedy, gdy zapewniają większe korzyści niż te koszty. Tworzenie testów to umiejętność jak każda inna, wymaga określonego doświadczenia i wiedzy, aby odnieść sukces. Bez wystarczającego doświadczenia bardzo łatwo jest nawet doświadczonym programistom tworzyć testy jednostkowe niskiej jakości, niskiej wartości i / lub kosztowne, które nie są opłacalne. Zwłaszcza biorąc pod uwagę, jak trudno jest ocenić wartość testu jednostkowego.

Ponadto testowanie jednostkowe to tylko jeden ze sposobów na poprawę jakości kodu, ale nie jedyny. W pewnych okolicznościach iw przypadku niektórych zespołów może to nie być najskuteczniejszy sposób na podniesienie jakości oprogramowania.

Należy pamiętać, że wkładanie wiele wysiłku w testowanie jednostkowe nie gwarantuje jakości oprogramowania. Możliwe jest również wytwarzanie oprogramowania najwyższej jakości bez jakichkolwiek testów jednostkowych.

Cóż, moja firma nie poszła na TDD ani testy jednostkowe. Szczerze mówiąc, nie wiemy, jak to zrobić. Możemy to oczywiście zrobić dla głupich funkcji, takich jak CapitalizeString (), itp., Ale nie wiemy, jak to zrobić w przypadku bardzo złożonych systemów ze skomplikowanymi obiektami. Ponadto większość ankietowanych osób ma zerowe lub ograniczone doświadczenie. Wygląda na to, że testy jednostkowe są popularne wśród tłumu SO, ale nie są szczególnie duże w dostępnej puli zadań.

TDD to osobny temat. Jesteśmy moralnie przeciwni TDD. Nie jesteśmy programistami kowbojami, ale wierzymy, że ogranicza to kreatywność i elastyczność w projekcie. Co więcej, posiadanie kodera, który napisał funkcję testów jednostkowych, nie ma sensu. Kiedy coś robię, koduję wszystkie skrajne przypadki, które przychodzą mi do głowy. Potrzebuję innego mózgu do szukania rzeczy, które mogłem przegapić. Nie mamy tego. Zespoły są małe i samodzielne.

Krótko mówiąc, nie wierzymy w TDD, ale chcielibyśmy przeprowadzić testy jednostkowe. Po prostu nie mamy doświadczenia, aby to zrobić i nie możemy go łatwo znaleźć.

Istnieje wiele firm, które tak naprawdę nie robią nic zgodnie z najlepszymi praktykami. Żadnych recenzji kodu, żadnych testów jednostkowych, żadnych planów testowania, nic, tylko przy siedzeniu ich spodni.

Skorzystaj z okazji, aby skłonić ich do korzystania z platformy Continuous Integration i tworzenia testów jednostkowych! Łatwy sposób, aby zaimponować mocom i jednocześnie zwiększyć jakość i stabilność kodu

Edycja: Jeśli chodzi o powód, myślę, że po prostu nie są świadomi obecnych narzędzi, które sprawiają, że CI i testy jednostkowe są niezwykle łatwe.

Z tego, co widziałem, wiele firm ma ogromne, wysoce powiązane bazy kodu, których praktycznie nie można testować jednostkowo. Nie mają również przyzwoitych testowalnych wymagań, więc testy jednostkowe będą testować pod kątem rzeczywistych wymagań „powykonawczych”.

Nie sądzę, by lenistwo było główną przyczyną złych testów jednostkowych. Dla mojej firmy ograniczenia czasowe i postawa „po prostu zrób to sam” są największymi przeszkodami dla przeprowadzania testów jednostkowych. Ponadto miejsca, w których nasze systemy zawodzą, są zwykle bardziej na poziomie integracji (usługi, dostęp do baz danych, złożone zapytania, które wymagają określonych danych do testowania), a nie na „poziomie jednostki”. Te rzeczy są po prostu trudniejsze do przetestowania, a jeśli ledwo masz wystarczająco dużo czasu, aby wykonać tę funkcję, prawdopodobnie nie będziesz miał czasu na wykonanie żadnych przydatnych testów w tym samym czasie.

Testowanie jednostkowe powinno być naturalną częścią przepływu pracy tworzenia kodu, podobnie jak kompilator.

Wymaga to jednak edukacji kierownictwa w zakresie korzyści płynących z testowania jednostkowego. Młodsi deweloperzy mają jednak stosunkowo niewielkie szanse na taki wpływ. Zatem to, czy firma jest zwolennikiem testów jednostkowych, zależy od tego, czy ma starszego programistę lub architekta, który jest zwolennikiem testów jednostkowych.

Myślę, że jest to odpowiedź na Twoje pytanie „czego brakuje i dlaczego nie więcej firm przeprowadza testy jednostkowe” . :-)

Prawdopodobnie jest to połączenie kilku rzeczy, o których już wspomniałeś. Trudno jest zmierzyć oszczędności kosztów TDD. Jeśli chcesz zlecić outsourcing IT, możesz pokazać, ile płacisz rocznie za pracowników, w porównaniu z kosztami zawarcia umowy; jest bardzo konkretny. Jak powiesz: „Och, ten test wykrył błąd, którego debugowanie i naprawianie zajęłoby mi 4 godziny…”?

Powodem, dla którego w niektórych miejscach go nie używają, jest po prostu to, że zarówno rozpoczęcie, jak i kontynuacja wymagają dużo pracy. Fakt, że pisanie testów jednostkowych zajmuje mniej więcej tyle samo czasu, co pisanie rzeczywistej funkcjonalności, wydaje się niektórym menedżerom, że zmniejszasz produktywność programisty o połowę.

Oprócz tego budujesz zespół (lub kogoś), kto musi zainstalować infrastrukturę i ją utrzymywać.

Jak mówi Alan , wiele miejsc po prostu nie stosuje najlepszych praktyk - chcą po prostu zobaczyć coś namacalnego.

Myślę, że programista musi po prostu zacząć to robić. Kilka prostych testów na początek można łatwo uzasadnić jako część rozwoju.

Coś w rodzaju testu jednostkowego jest prawie zawsze konieczne, aby uzyskać szybki debugowanie. Po prostu wyjaśnij, o ile szybciej można uruchomić test, niż ustawić poprawne dane wejściowe, ustawić punkt przerwania debuggera, uruchomić aplikację itp.

Udokumentuj test w swoim kodzie. Po prostu umieść komentarz wyjaśniający, gdzie jest test i jak go uruchomić. Przyszli programiści zobaczą to i miejmy nadzieję, że testy się rozprzestrzenią!

Testy jednostkowe to jedno z tych terminów z czarnej skrzynki, które większość ludzi słyszała, ale nie wiem, co dokładnie składa się na test jednostkowy, od czego zacząć, jak je napisać, jak właściwie przeprowadzać testy, co dokładnie powinny testować itp. . itd itd.

W wielu przypadkach niepewnym programistom łatwiej jest po prostu odrzucić je jako niepotrzebne lub jako oblodzenie, którego potrzebują tylko „programiści na poziomie przedsiębiorstwa”.

Jestem wielkim fanem testów jednostkowych, a także partnerem w firmie realizującej projekty kontraktowe dla różnych typów klientów. Za miesiąc zajmiemy się 3-4 różnymi projektami o różnej wielkości.

Jeśli wydaje się, że projekt będzie jednorazowy, nie zamierzam dużo inwestować w testy jednostkowe, ponieważ te testy jednostkowe nie opłaca się mojej firmie. W tego typu projektach zamierzam przeprowadzić testy jednostkowe rzeczy, których nie jestem pewien / nie znam lub które mogą się często zmieniać (na przykład parser dla źródła danych, którego nie kontroluję).

Natomiast jeśli buduję coś, o czym wiem, że będzie miało długą żywotność, jest to większe dzieło, nad którym będę pracował przez wiele iteracji, lub będzie miało duży wpływ na moich klientów, jeśli wystąpi błąd , Zamierzam zainwestować w więcej testów jednostkowych. Ponownie priorytet testów obraca się wokół niepewnego / nieznanego / zmieniającego się kodu.

Myślę, że testy jednostkowe powinny kręcić się wokół złożoności zadania, a także tego, czy się opłacą. Nie ma sensu pisać dodatkowego kodu, który nie zostanie wykorzystany.

Z mojego doświadczenia wynika, że ​​tak naprawdę zależy to od oprogramowania, które piszesz. Zauważyłem, że pisanie testów jednostkowych dla interfejsu użytkownika jest niezwykle trudne. Używam testów jednostkowych tylko dla części systemu, które mają określone wejście / wyjście.

Brakuje mi testów jednostkowych - to po prostu ułatwia życie.

To nie jest naprawdę jest wystarczający powód, aby firma przyjęła testy jednostkowe.

Wystarczającym powodem może być „tańszy” (i / lub „lepszy”): co nie jest tak łatwe do udowodnienia w przypadku testów jednostkowych.

Jedynym dobrym powodem może być „pisanie testów jednostkowych to najlepsze wykorzystanie czasu programistów”, co jest naprawdę trudne do udowodnienia w IMO: i może być prawdą w niektórych miejscach, w przypadku niektórych programów, z niektórymi programistami, a nie w innych.

Jest wielu programistów, którzy nie myślą o świecie testów jednostkowych: w tym tacy, którzy uważają, że inne formy testowania (np. Zautomatyzowana integracja / testy funkcjonalne) mogą być tańsze i bardziej wartościowe, na przykład Czy jestem jedynym programistą, który tego nie robi? t jak testy jednostkowe?

Oczywiście w idealnym świecie nie można argumentować przeciwko przeprowadzaniu testu jednostkowego.

Jednak to, czy napiszesz test jednostkowy, zależy od wielu rzeczy:

• W jaki sposób oprogramowanie będzie używane. Gdybyś pisał oprogramowanie tylko dla siebie, czy napisałbyś testy jednostkowe? Prawdopodobnie nie. Jeśli piszesz gotowe oprogramowanie do sprzedaży komercyjnej, prawdopodobnie tak.

• Ile osób obsługuje kod… jeśli jesteś tylko Ty, możesz go znać na tyle dobrze, aby po wprowadzeniu zmiany mieć pewność, że szybkie przejrzenie kodu jest wystarczające, aby upewnić się, że nic się nie zepsuło. Jeśli inne osoby, które pierwotnie nie pisały kodu, muszą go teraz utrzymywać, test jednostkowy pomoże im przekonać się, że kiedy zaktualizują kod w celu naprawienia dużego (który oczywiście nie został przechwycony w teście jednostkowym!), Niczego nie zepsuli. .

• złożoność kodu: tylko kod testowy, który wymaga testu. Metoda przypisywania zmiennych w jednym wierszu nie wymaga testowania. Prawdopodobnie działa metoda 50-liniowa z wieloma ścieżkami wykonania.

• Praktyczne rozważania komercyjne: Faktem jest, że pisanie testów jednostkowych zajmuje więcej czasu niż nie. Jeśli piszesz oprogramowanie prototypowe, które ma niepewną komercyjną przyszłość, to jest opłacalne między szybkim posiadaniem kodu, który teraz działa wystarczająco dobrze, a posiadaniem kodu przetestowanego jednostkowo w 2 tygodnie, który działa lepiej. Czasami opłaca się szybko dowiedzieć się (apetyt konsumentów), czy oprogramowanie będzie miało krótką półkę i przejść do następnego projektu.

i jak zauważyli inni, test jest tak dobry, jak osoba, która go napisała.

Głównym powodem jest to, że wielu programistów i menedżerów ds. Rozwoju nie ma pojęcia, że ​​istnieją testy jednostkowe ani jak z nich korzystać.

Drugim powodem jest to, że testy jednostkowe można stosować (w rozsądny sposób) tylko z kodem, który już spełnia pewne standardy jakości. Są szanse, że jakaś istniejąca baza kodów nie należy do tej kategorii.

Trzeci powód to lenistwo i / lub taniość.

Ponieważ testy jednostkowe są przydatne tylko wtedy, gdy napiszesz testowalny kod. A pisanie testowalnego kodu jest trudne. A ludzie są leniwi i / lub tani.

EDYCJA: dopracowany „leniwy” jako „leniwy i / lub tani”; W rzadkich przypadkach ludzie mają umiejętności, zdolności i wolę pisania testów, ale mają coś innego do zrobienia, co bardziej bezpośrednio wpływa na wynik finansowy.

Myślę, że część problemu polega na tym, że programiści oczekują od ludzi biznesu tego samego zestawu wartości i naprawdę zależy im na odpowiedzi na pytanie „czy powinniśmy testować jednostkowo, czy nie?”. Nie otrzymujemy wcześniej zgody firmy na używanie języka wysokiego poziomu zamiast języka asemblera - jest to zwykle rozsądny sposób na wykonanie pracy.

Chodzi o to, że jesteśmy jedynymi uprawnionymi do wykonania telefonu (co nie oznacza, że ​​wszyscy mamy taką samą wiedzę na dany temat). Co więcej, nawet jeśli Twój zespół, z powodów politycznych, nie przeprowadza testów jednostkowych (lub nie określa swojej-metody-dnia), generalnie nie oznacza to , że nie możesz tego zrobić.

Prawda jest taka, że ​​nie możemy naprawdę udowodnić zwrotu z inwestycji w większości rzeczy, które robimy ze zbyt dużą szczegółowością. Dlaczego testy jednostkowe są utrzymywane na tym nierozsądnym / nietypowym standardzie dowodu, jest poza mną ...

Ludzie są leniwi i przyjmują zmianę tylko wtedy, gdy są do tego zmuszeni.

Moje 2 centy:

• Wymaga pewnego wykształcenia i dyscypliny, ale nowi absolwenci przychodzą już z odpowiednią wiedzą.
• Narzuty związane z testami można zmniejszyć dzięki lepszym narzędziom i to się również dzieje (refaktoryzacja itp.)

Więc to tylko kwestia czasu.

Trwa debata Martin-Coplien, w której Bob Martin twierdzi, że:

„obecnie nieodpowiedzialne jest wysyłanie przez programistę linii kodu, których nie wykonał w teście jednostkowym”.

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Jeśli chcesz sprzedać wszystkim testowanie, wykonaj następujące czynności:

1. Napisz kilka testów.
2. Powiadom innych programistów, którzy zmieniają kod i nie zdają testu (-ów).
3. Naprawią swój kod.
4. Teraz możesz wydać bez tych konkretnych błędów.

Nawet kierownik mógłby to zrozumieć.

Firmy nie przeprowadzają testów jednostkowych z tego samego powodu, dla którego wiele stron internetowych jest napisanych źle - ignorancja i ludzie trzymający się starych nawyków. W mojej firmie, odkąd rozpoczęliśmy testy jednostkowe (z Nunit i Typemock ), osiągamy większe pokrycie kodu i wypuszczamy oprogramowanie w krótszym czasie na rynek.

Podobnie jak większość dobrych pomysłów, przyjęcie ma więcej wspólnego z zależnością od ścieżki organizacyjnej niż z jakością pomysłu.

W większości firm, które dostarczyły produkty, utworzono znaczący dział kontroli jakości z kierownikiem wyższego szczebla ds. Kontroli jakości. Testowanie to lenno zespołu ds. Kontroli jakości.

Zespół ds. Kontroli jakości raczej nie napisze kodu testów jednostkowych, ponieważ firma zazwyczaj nie zatrudnia zespołu ds. Kontroli jakości za pomocą zaawansowanych programistów.

Zespół programistów niechętnie pisze kod testowy, ponieważ powoduje to konflikt z zespołem QA.

Widziałem większe zainteresowanie i przyjęcie testów jednostkowych w grupach, w których kontrola jakości nie została wydzielona do oddzielnej funkcji zawodowej

Proste pisanie i aktualizowanie testów jednostkowych kosztuje. W większości firm poprzednie oprogramowanie nie ma testów jednostkowych i jego napisanie będzie zbyt drogie. Więc nie robią tego, a to wydłuża proces programowania, więc nie dodają go również do nowych funkcji.

Większość firm jest bezużyteczna. Oczywiście nie ten, dla którego ty (lub ja) pracujesz.