Czy jako profesjonalny programista nie wolno pisać testów jednostkowych? [Zamknięte]

Zastanawiasz się tylko nad zaletami i wadami TDD / automatycznych testów jednostkowych i szukasz opinii społeczności na temat tego, czy profesjonalni programiści mogą pisać aplikacje bez wspierania testów jednostkowych?

Aby przetestować co?

Jeśli mówisz o 100% pokryciu kodu, jest to niezwykle rzadkie, nieprzydatne i często niemożliwe. W ten sam sposób testowanie kodu związanego z CRUD jest stratą czasu i byłoby bardzo nieprofesjonalne spędzać godziny na pisaniu kodu, którego nie potrzebujesz, zamiast robić coś naprawdę przydatnego.

Teraz, jako programista, musisz wiedzieć, jak pisać testy jednostkowe i gdzie ich potrzebujesz.

Teoria

Istnieje powszechne nieporozumienie, że testy jednostkowe służą do testowania „jednostek” .
Testy jednostkowe, podobnie jak wszystkie inne testy, funkcjonalność testu . Po prostu nic innego nie można przetestować.

Jednak funkcjonalności złożonego systemu często nie można skutecznie przetestować.
Powiedzmy, że użytkownik naciska przycisk „Usuń” i nic się nie dzieje. Dlaczego? W bazie danych może znajdować się błąd, połączenie może zostać zerwane, podstawowa logika może działać nieprawidłowo, a nawet operacja może się powieść, ale interfejs nie został poprawnie zaktualizowany. Każda warstwa może zawierać wiele funkcji, które się nawzajem wywołują, i nie zawsze jest jasne, gdzie jest błąd.
Testy jednostkowe oparte są na paradygmacie oddzielania komponentów i testowania ich indywidualnie.

Po raz kolejny nie gwarantuje, że cały system będzie działał, ale upraszcza testowanie.

TDD nie jest samo w sobie wymogiem. Upraszcza kodowanie, zmuszając programistę do odpowiedzi w pierwszej kolejności: „co właściwie zamierzam napisać?”.

Koszty

Wielu uważa, że ​​nie pisząc testów, oszczędzają czas. Źle. Myśląc strategicznie, koszt błędu rośnie wykładniczo wraz z upływem czasu od pojawienia się do wykrycia.

Załóżmy, że popełnisz błąd w kodzie i wykryje go i naprawisz tego samego dnia. Koszt to X USD .
Załóżmy, że błąd pozostaje niewykryty i przechodzi do cotygodniowej kompilacji wewnętrznej. Na szczęście QA to wykrył, zgłosił błąd w narzędziu do śledzenia błędów, ten problem był przedmiotem 5-minutowej dyskusji na spotkaniu 5 osób itp. Wreszcie to naprawiłeś. Koszt to suma siły roboczej wydanej przez wszystkich i może wynosić 3 USD * X w tym przypadku.
Co się stanie, jeśli błąd przejdzie w testy beta i obejmie więcej osób? Powiedzmy Powiedzmy, $ 10 * X .
Jeśli pozostanie niezauważony przez długi czas, trafił do 1000 klientów (mam nadzieję, że nie do miliona!), 10 z nich to wykryło, podnieśli dyskusję z personelem wsparcia, niektórzy mogą nazywać się szefem, koledzy z drużyny próbują to odtworzyć itd. itd. Wreszcie błąd wraca do Ciebie i naprawiasz go. Ile łącznie? Cóż więcej niż 50 $ * X .

Jak widzisz, błąd prędzej czy później wróci do ciebie (lub twojego kolegi). Jedyna różnica polega na tym, kiedy to się dzieje i ile to kosztuje.
Testy jednostkowe skracają cykl życia błędów, a tym samym obniżają koszty.

Pro's

• Testy jednostkowe pozwalają programistom lepiej kodować . Tak proste jak to.
• Pozwalają zaoszczędzić twój czas;
• Zmniejszają koszty;
• Testy jednostkowe działają na żywo wraz z testowanym kodem. Na każde żądanie zmiany (które dzieje się cały czas) testy dostosują się.

Cons

Widzę tylko jedną wymówkę, żeby nie pisać testów. Jeśli piszesz prototyp, np. Coś, co nigdy nie trafi do innych ludzi. A może piszesz coś do jednorazowego użytku.

Oczywiście, nie wolno pisać testów jednostkowych dla małych wewnętrznych narzędzi pomocniczych lub narzędzi testowych lub scenariuszy, w których biznes naprawdę potrzebuje rzeczy innych niż jakość, a Ty jako profesjonalny programista odkrywasz, że możesz zrobić oprogramowanie i działać równie szybko bez.

Z mojego doświadczenia wynika, że ​​95% błędów, które mogą zostać wykryte przez testy jednostkowe, pochodzą z wywołań warstwy danych, szczególnie po zmianach w projekcie bazy danych. Jeśli korzystasz z bazy danych, po prostu przetestuj każdą metodę dostępu do niej. Testy nie muszą nawet być skomplikowane, a jedynie kontrola rozsądku.

W odpowiedzi na twoje pytanie - jeśli masz dostęp do bazy danych i jesteś profesjonalnym programistą, powinieneś użyć testów jednostkowych. W przeciwnym razie to zależy.

To zależy od sposobu użycia aplikacji. Czy jest to aplikacja o znaczeniu krytycznym? Czy jest to prosta aplikacja weryfikacyjna używana tylko wewnętrznie przez programistów? Podczas pracy nad podstawowymi aplikacjami dla Twojej firmy należy przeprowadzić tyle testów jednostkowych, ile jest to konieczne, aby zapewnić uwzględnienie decyzji biznesowych. W zależności od firmy są to aplikacje, które widzą klienci, a błędy mogą kosztować pieniądze. Dobrze wykonane testy jednostkowe mogą być bardzo pomocne w zapewnieniu działania aplikacji po ich wdrożeniu. Ale to nie jest lekarstwo na wszystkie i testy na ludziach powinny być nadal wykonywane. Proste aplikacje wewnętrzne (lub pomocnicze) nie wymagają testów jednostkowych, ale nadal powinny być dobrze napisane.

TDD nie polega wyłącznie na pisaniu testów. Chodzi o upewnienie się, że Twój kod jest łatwo testowalny. Ponadto kod łatwiejszy do odczytania / debugowania / konserwacji jest również łatwiejszy do przetestowania. Najczęściej kod, który nie jest łatwy do przetestowania, jest zgodny z wzorcami i zasadami OO, takimi jak SOLID. Jako profesjonalny programista uważam, że Twój kod powinien być zawsze tak zapisywany.

Zdecydowanie nie chcesz „bez testowania”. Pisząc testy jednostkowe, masz przynajmniej pewność, że Twój kod pasuje do twoich testów (chociaż musisz upewnić się, że testy są zgodne ze specyfikacją).

Nie skończysz, jeśli wszystko, co masz, to testy jednostkowe. Prawdopodobnie nadal musisz wykonywać testy integracyjne i testy kompleksowe (z czasem gromadzić przypadki testowe, aby wykryć regresje błędów).

Mam zamiar wyjść na kończynę i powiedzieć, że jest to głównie subiektywne i zależy od twoich celów. tl; dnr: Dobrze jest to zrobić, ale bycie dogmatykiem po prostu doprowadzi do kolejnych problemów.

Testy TDD / Unit poprawią stabilność twojego kodu. Ułatwiają wprowadzanie zmian bez znajomości bazy kodu, pozwalają szybciej refaktoryzować, dają pewność, że nie robisz czegoś głupiego. Testy jednostkowe mogą być również stratą czasu. Czas, który można poświęcić na pisanie kodu. Może także pozwolić ci oszukać się, że twój kod działa, gdy nie działa, jeśli ślepo go przestrzegasz.

Jeśli pracujesz dla firmy, która wspiera najlepsze praktyki i daje ci czas na ich wdrożenie, a potrzebujesz aplikacji, która będzie trwała, to naprawdę najlepiej jest dla wszystkich, aby używać i ćwiczyć testy jednostkowe i recenzje kodu. Posiadanie zespołu ds. Kontroli jakości może być akceptowalnym substytutem, jeśli programiści go nie nadużywają. Jeśli piszesz prototyp (nawet produkcyjny), może to być szybsze niż testy dymu.

Jeśli pracujesz nad czymś, gdzie bałagan nie będzie końca świata, prawdopodobnie mniejszy zasięg jest w porządku. Transakcje finansowe? Dużo. Jeśli masz zespół silnych programistów, którzy znają bazę kodów, współpracują dobrze i nie ma obrotów, prawdopodobnie potrzebujesz mniejszego zasięgu. Itp.

Więc prawdopodobnie będzie to jakaś funkcja

• Wielkość zespołu / obrót
• Pożądany okres trwałości aplikacji
• Aplikacja i jak krytyczne są awarie
• Przewidziany czas na wdrożenie najlepszych praktyk w stosunku do harmonogramu rozwoju
• Umiejętności zespołu (nie oznacza to, że jest się dobrym programistą, oznacza, że ​​nie powinieneś pisać testów jednostkowych, ale zespół bez młodszych programistów może latać przy siedzeniu spodni z większym powodzeniem)

Istnieje wiele sytuacji, w których niedopuszczalne byłoby pisanie testów jednostkowych. TDD jest teraz „włączony”, ale to nie jest srebrna kula.

Profesjonalnie jest pisać testy jednostkowe, które pozwolą Ci zaoszczędzić czas i łzy!

Jest misconception that Unit test finds bugs. Cóż, to po prostu NIE jest prawdą we wszystkich przypadkach. Testowanie jednostkowe nie polega na wyszukiwaniu błędów ani wykrywaniu regresji. Jest to z definicjiexamine each unit of your code separately . Ale kiedy aplikacja działa naprawdę, wszystkie te jednostki muszą ze sobą współpracować, a całość jest bardziej złożona i subtelna niż suma niezależnie przetestowanych części.

Dlatego celem testów jednostkowych (w ramach procesu TDD) jest solidne projektowanie komponentów oprogramowania.

Edycja: Istnieje jeden wyjątek, w którym testy jednostkowe faktycznie wykrywają błędy. Dzieje się tak, gdy dokonujesz refaktoryzacji lub restrukturyzacji kodu jednostki, ale nie chcesz zmieniać jej zachowania. W takim przypadku testy jednostkowe często pozwalają stwierdzić, czy zachowanie jednostki uległo zmianie.

Czy jako profesjonalny programista nie wolno pisać testów jednostkowych?

Nie.

Bez pytania - powinna to być jedna z pierwszych lekcji, których uczy się świeższy. Państwo musi opracować testy jednostkowe, aby udowodnić, że kod działa zanim powiesz QA, że kod jest gotowy do testów. Niespełnienie tego warunku zwiększy koszty projektu i obniży morale zespołu.

Jak dokładne powinny być te testy jednostkowe?

Oto test lakmusowy: jeśli QA wykryje błąd w twoim kodzie, czy będziesz wygodnie korzystać z testów jednostkowych, aby udowodnić swojemu szefowi należytą staranność?

Jeśli twoja odpowiedź brzmi „nie”, powinieneś przygotować lepszy test jednostkowy (lub testy).
Jeśli Twoja odpowiedź brzmi „Tak”, kod jest gotowy do weryfikacji.

Czy jako profesjonalny programista nie wolno pisać automatycznych testów jednostkowych?

Tak.

Zwłaszcza jeśli czas i wysiłek włożony w pisanie automatycznych testów jednostkowych przewyższy korzyści uzyskane w wyniku testu. Obejmuje to między innymi kod interfejsu użytkownika, który może być trudny do wyszydzenia.

Podkreślenie: nie mówię, że nie można napisać automatycznych testów jednostkowych dla kodu interfejsu użytkownika. Mówię tylko, że z mojego doświadczenia czasami trudno jest napisać automatyczne testy jednostkowe dla niektórych kodów interfejsu użytkownika.