Kto zajmuje się rozwojem opartym na testach?

Pracuję w przestrzeni korporacyjnej przez ostatnie 4 i pół roku i zauważyłem, że ogólnie rzecz biorąc, przedsiębiorstwa nie są sprzyjającymi środowiskami dla stylu testowania jako pierwszego testu. Projekty mają zazwyczaj stały koszt, stały harmonogram i styl wodospadu. Wszelkie testy jednostkowe, jeśli w ogóle są wykonywane, zwykle następują po opracowaniu w fazie kontroli jakości i przeprowadzane przez inny zespół.

Przed rozpoczęciem pracy w przedsiębiorstwie konsultowałem się z wieloma małymi i średnimi firmami i żadna z nich nie była skłonna zapłacić za projekt testowy w stylu testowym. Zwykle chcieli, aby prace rozwojowe rozpoczęły się natychmiast lub po krótkim okresie projektowania: tj. Coś bardziej zbliżonego do Agile, chociaż niektórzy klienci chcieli, aby wszystko było odwzorowane podobnie do wodospadu.

Z jakimi typami sklepów, firm i klientów najlepiej działa programowanie testowe? Jakie rodzaje projektów sprzyjają TDD?

Każdy wiersz kodu, który piszę, wykorzystuje programowanie testowe. Jeśli zarząd nie jest w pierwszej kolejności przy pisaniu testów, nie mówię o tym zarządowi. Uważam, że rozwój oparty na testach jest lepszym procesem.

Mój szef nakarmił mnie dzisiaj dobrym, myślę, że ukradnę to tak, jakby ukradł to komuś innemu.

„Czy spodziewałbyś się, że stolarz zmierzy deskę, zanim ją pokroi?”

W liceum chodziłem do sklepu z drewnem i przez cały czas pracowałem przy budowie. Nasza mantra była zawsze „mierz dwa razy, raz cięta”, po czym nastąpił sarkastyczny „Ciąłem ją i przecięłem jeszcze raz, a ona wciąż była za krótka!”

Jeśli wykonasz test później, utworzysz przeróbkę, ponieważ kod, który napiszesz, będzie trudny do przetestowania. Kiedy najpierw przetestujesz, a nawet przetestujesz trochę w środku, ale przed zatwierdzeniem, stworzone przez Ciebie oprogramowanie będzie łatwiejsze do przetestowania. Przedsiębiorstwo, które tworzy testy jednostkowe po napisaniu kodu produkcyjnego w celu spełnienia listy kontrolnej, marnuje wysiłek.

Integracja z istniejącym trudnym do przetestowania oprogramowaniem spowoduje także dodatkowy wysiłek, ponieważ będziesz musiał stworzyć szwy testowe, aby móc kontrolować zależności, które zużywa Twój błyszczący, nowy kod testowy. W niektórych przypadkach, na przykład w ramach, które intensywnie wykorzystują globalne obiekty państwowe i boskie, może to być bardzo trudne do osiągnięcia. Dostrzegana trudność programowania opartego na testach jest często spowodowana brakiem doświadczenia w pisaniu dobrych testów i próbach testowania ściśle powiązanego kodu.

Możesz przetestować kod napędu nawet w projekcie wodospadu, jest to dyscyplina inżynieryjna, a nie technika zarządzania projektem.

W żadnym wypadku nie jestem fanatykiem TDD, ale uczy cię wiele o projektowaniu oprogramowania.

Miejcie ze sobą, bo będzie to miało wyraźny smak .Net: p

W odniesieniu do rodzajów projektów, które podlegają podejściu pierwszemu testowi, na niektóre rzeczy uważam:

• czy masz do czynienia z istniejącą bazą kodu? Modernizacja tego zestawu testowego jest często zbyt droga. Dowiedz się, ile jest odziedziczonych długów technicznych
• niektóre platformy i frameworki są z natury nieprzyjazne dla testów. Ostatnie wrażenia, które zapadły mi w pamięć - na przykład SharePoint jest bardzo trudny (ale nie niemożliwy) dla TDD. W przypadku takich rzeczy może być konieczne skorzystanie z komercyjnego produktu izolującego, takiego jak TypeMock.
• niektóre metody wdrażania lepiej nadają się TDD niż inne. Na przykład ASP.Net z kodami - nie tak testowalne. ASP.Net MVC - testowalny. Silverlight z kodami - nie tak testowalne. Silverlight z MVVM - testowalny.

Ostatecznie, podczas gdy „organizacja” może wiele zrobić, aby wesprzeć przejście do testów, kluczową zmianą, która musi nastąpić, są umysły programistów. Zrezygnowałem z podejścia „najpierw napiszesz testy” i zamiast tego szukam możliwych do nauczenia momentów.

+1 w komentarzu mpenrow o nie informowaniu mgmt, jeśli mają z tym problem: p

Twoja sytuacja nie zmieni się szybko, a kluczem do jej przejścia jest uczynienie go częścią osobistej dyscypliny i bycie w tym dobrym, zanim spróbujesz narzucić ją innym. Jeśli możesz być przykładem tego, że działa, to twoi menedżerowie powinni zobaczyć obiektywne korzyści.

Możesz także robić dobre sprawy biznesowe:

• TDD można po prostu streścić jako „specyfikację, z którą system może się automatycznie zweryfikować”. Nie programuje się inaczej, nie buduje innego produktu.

• Testy jednostkowe są tak naprawdę tylko formą testów automatycznych; co pozwala komputerowi zrobić samemu to, co firma prawdopodobnie płaci ręcznie inżynierom zajmującym się produkcją mięsa. Zautomatyzowane testy przebiegają szybciej, bardziej konsekwentnie i - jeśli są dobrze napisane - zapewniają szybką, zwięzłą i dokładną informację zwrotną oraz opisy i wskazówki dotyczące problemu

• TDD, gdy jest wykonywane przez kogoś, kto wie, co robią, daje wyniki tak samo szybko, jak kod. Pojawi się krzywa uczenia się / szkolenia (a jeśli twoi inżynierowie pochodzą z krótkiego końca puli talentów, może to całkowicie zabić twoje szanse na przeforsowanie TDD - w tym przypadku najlepszym, co możesz zrobić, to kontynuować to i kierujcie je pytaniami zamiast TDD)

• TDD polega na przemyśleniu zadania przed jego uruchomieniem. Jest zgodny z zasadą „mierz dwa razy, odcinaj raz” - dodatkowe pomiary dodają marginalnego czasu do zadania, ale unikają wyrzucania najcenniejszych zasobów - godzin pracy).

... i tylko pamiętaj; najważniejsze, co możesz zrobić, to dawać przykład. Jeśli masz problemy z TDD, zainwestuj dodatkowe godziny w lepsze. Kiedy już będziesz biegły, po prostu zacznij robić to w pracy (czy menedżerowie naprawdę narzekaliby, że piszesz testy?). Stocz bitwę po jednej bitwie i rób kroki w jej kierunku - przejście na cały szew może doprowadzić do porażki, a wina spadnie na ciebie, jeśli będziesz za to mocno naciskać.

Ja robię. Jest to mój ulubiony sposób rozwoju i pracuję dla dużej firmy finansowej, która cieszy się, że mogę pracować w sposób, który uważam za odpowiedni, o ile dotrzymuję terminów i opracowuję kod jakości. Wykonane poprawnie, testowanie pierwszego rozwoju nie musi trwać dłużej niż testowanie po rozwoju i nie zapominajmy o innych korzyściach z testowania pierwszego rozwoju mniej wad poza testowaniem systemu później.

Kluczem do zrobienia TDD jest po prostu zrobienie tego w ramach pisania kodu, a jeśli to konieczne, nie mów nikomu, że to robisz. Nie musisz wyjaśniać wszystkiego, co robisz. Twój wynik końcowy to działający kod.

Jeśli wyjaśnisz „Piszę testy”, wówczas Potęgi, które są, mogą powiedzieć „Och, możemy to wyeliminować!” Ale jeśli nikomu nie powiesz, nadal masz testy jako pozostałość procesu kodowania.

Programowanie to coś więcej niż wpisywanie instrukcji roboczych do edytora. Jeśli ludzie nie mogą sobie z tym poradzić, chroń ich przed tą prawdą, dopóki nie będą gotowi z nią sobie poradzić. „Gotowy, by sobie z tym poradzić” oznacza w tym przypadku, gdy masz ukończony projekt lub dwa, wykonane na czas z solidnym, niezawodnym kodem i och tak, słuchaj, masz też testy jednostkowe.

Z przykrością muszę powiedzieć, że nie miałem okazji użyć go w prawdziwie klasycznym sensie pierwszego testu, więc nie mogę powiedzieć „ja! Ja! Robię to!”. Zakładam, że pytanie brzmi: „jakie branże / firmy używają TDD w całym świecie”, a nie „czy ktoś może zakraść TDD w ich codziennym życiu?”. Zgadzam się, że indywidualny programista może całkowicie zrobić TDD bez zmuszania całej grupy do zrobienia tego, po prostu nie sądzę, że o to chodziło w tym pytaniu.

Mam wrażenie, że słuchanie w branży jest takie, że częściej widzisz TDD w większości grup programistycznych w firmie w sytuacjach, gdy:

• Nie ma dużej istniejącej bazy kodu przed rozpoczęciem TDD

• Firma nie jest ogromna i dlatego nie ma wielu negatywnych odpowiedzi „zawsze tak robiliśmy w inny sposób”.

• Firma nie ma ogromnego wkładu w sformalizowany proces. Nie oznacza to, że nie można wdrożyć TDD, na przykład w firmie certyfikowanej CMMI - ale jeśli miałeś proces inny niż TDD, uzyskanie wszystkich procesów monitorowanych za pomocą CMMI może być poważną inwestycją.

• Testy można wykonywać za pomocą skryptów - jest to najbardziej złożona baza kodu, ponieważ nawet jeśli nie możesz łatwo napisać skryptów do najbliższej warstwy dla użytkownika, możesz napisać skrypt do niektórych elementów wewnętrznych. Uważam jednak sytuacje z dobrze rozwiniętymi opcjami automatyzacji testów za najsłodsze miejsca dla TDD, ponieważ są one oparte na ponownym uruchamianiu i niezniszczaniu całego zestawu testów, w których bardzo szybko potrzebujesz opinii na temat testowania. Myślę, że samodzielna aplikacja internetowa jest dobrym celem TDD, system z dużą integracją COTS lub danymi wejściowymi, które nie są oparte na GUI, może być trudny.

• Systemy w stanie nie prototypowym. Idealnie następna duża wersja po prototypie - w której ukończono weryfikację koncepcji i sfinansowano projekt, ale wszyscy wiedzą, że kolejna próba musi skoczyć na jakość.

• Interesariusze zainwestowani w ten proces.

Próbowałem tam, gdzie to możliwe - ale myślę, że tak naprawdę zależy to od środowiska korporacyjnego, w którym się znajdujesz. Pracowałem w branży gier przez wiele lat (jako btw jako artysta) i nie było koncepcji TDD - tylko podejście QA brutalnej siły. Przeszedłem do tworzenia stron internetowych i jeszcze nie pracowałem w agencji z jakimkolwiek formalnym uznaniem (lub znajomością ...) testów jednostkowych / TDD. To samo dotyczy większości moich rówieśników w branży, którzy pracują w wielu dyscyplinach.

W agencji zorientowanej na sprzedaż TDD oferuje klientowi bardzo krótki krótkoterminowy zwrot z inwestycji, dlatego trudno jest sprzedać kierownikom liniowym przy ustalaniu zakresu projektu. Im większy projekt, tym bardziej staje się przekonujący.

Biorąc pod uwagę, że książki takie jak Death March wskazują na powszechne zjawisko, tj. Przemysł nękany przez „kryzys” i „kamień milowy” rozwoju - zakładam, że TDD jest prawdopodobnie rzadkie poza dobrze finansowanymi startupami lub monolitycznymi sklepami dla przedsiębiorstw. To nie jest tak, że ludzie tam nie wierzą w wartość TDD - ale to zbyt abstrakcyjne, aby sprzedawać ich klientom.

Sam próbuję dostać się do TDD. Myślę, że dopóki podążasz trasami, które już znasz (codzienna praca), jest to dość proste. Ale po prostu nie mogę objąć głowy testami części interfejsu użytkownika lub gdy trzeba wymyślić nowe rozwiązanie jakiegoś problemu, z którym wcześniej się nie spotkałem. Lub używając frameworku, którego nie znasz.

Sądzę więc, że musisz przeprowadzić jakieś testy LearningTest, osobne sprawdzenie poprawności koncepcji, a następnie napisać je od nowa itp. Czy się mylę?

I (wiem, że to stary, ale jeszcze nie widziałem dobrej odpowiedzi): jak kodujesz algorytmy za pomocą TDD (kiedy wyniki mogą być zbyt skomplikowane, aby naprawdę łatwo „potwierdzić”)?

Naprawdę widzę pozytywne strony TDD i im na łódce, ale dla początkujących jest to bardzo trudne, gdy kod, który piszesz, zajmuje Ci prawie dwa razy więcej czasu (a masz rówieśników, którzy wcale nie widzą zalet i kpią z ciebie z RAD)

Próbowałem kilka razy i zadziałało świetnie. Niestety przez większość czasu, jeśli mogę ręcznie przetestować aplikację, odkładam testy jednostkowe, dopóki nie czuję się zbyt znudzony, aby wdrożyć coś innego lub pojawia się błąd, którego nie mogę łatwo naprawić.

Robię to. Postęp naszych historii użytkowników jest śledzony na tablicy Kanban, która ma „Ma test?” kolumna po lewej stronie (powyżej) rozwoju.

Ten nieco nietypowy układ uwydatnia jedną zasadę: nieudany automatyczny test akceptacyjny (zwykle kilka z nich) musi istnieć. Musi być identyfikowalny do wymagań klienta. Testy akceptacyjne wynikają z warunków satysfakcji , które wynikają z rozmów rozpoczynających się od karty opowieści . Ułatwiam regularne warsztaty, podczas których przeprowadzamy burzę mózgów, identyfikujemy luki i opracowujemy kluczowe testy akceptacyjne, które zapewniają, że wartość użytkownika jest dostarczana po ich przejściu ( definicja ukończenia ). To wspólne działanie z udziałem programistów, analityków biznesowych, a czasem testerów.

Pętla testowania akceptacji jest dość długa: ukończenie historii może zająć kilka dni. Opracowanie ma własne, krótsze pętle sprzężenia zwrotnego TDD.

„[... bez stylu pierwszego testu ...] Bardziej zbliżony do Agile…”

Jest to całkowite wprowadzenie w błąd Agile. Definicja „Gotowe” jest kluczowym elementem Agile, a jednym z filarów, na których opiera się, jest automatyczne testowanie akceptacji (to, co opisałem powyżej, jest jednym ze sposobów, aby to zrobić.) Jeśli jako metodę implementacji Agile stosuje się programowanie ekstremalne (XP), to Zalecane są ATDD / BDD i TDD.

Robię to, ale generalnie tylko w przypadku komponentów innych niż interfejs użytkownika, a kiedy wiem, że nie mogę zachować całego algorytmu modułu w mojej głowie za jednym razem, lub gdy moduł jest nową częścią dowolnego systemu, nad którym pracuję, więc nie mogę polegać na większości bibliotek, z których korzystam, aby były wysoce debugowane.

Zasadniczo robię to, gdy złożoność wymagań oznacza, że ​​w przeciwnym razie mógłbym się zgubić w kodzie.

Rozpoczęcie jest trudnym nawykiem i wymaga wpisu do zarządu, ale kiedy testy zaczynają się przełamywać w połowie rozwoju, może to być ratowanie życia!

Chciałem zadać to samo pytanie, aby zobaczyć, ile firm faktycznie ćwiczyło TDD.

Przez 11 lat programowałem profesjonalnie, tylko dwie ostatnie organizacje były świadome TDD (dotyczy to prawie 5 lat, do tego czasu TDD nie było tak popularne jak obecnie). Przejdę do sedna i odpowiem na twoje pytanie, zanim przejdę do mojej oferty sprzedaży TDD :)

W ostatniej firmie, w której pracowałem (internetowy akademicki wydawca nauk humanistycznych i kolekcji naukowych), wiedzieliśmy, że musimy ćwiczyć TDD, ale nigdy do tego nie dotarliśmy. W naszej obronie mieliśmy bazę kodu na 250 tys., Więc dodawanie testów do niestabilnej bazy kodu o takim rozmiarze wydawało się nie do pokonania (teraz czuję się winny, pisząc to!). Nawet najlepsi z nas popełniają błędy .

Każdy, kto wykonał nawet niewielką ilość TDD, wie, jak bolesne mogą być testy uzupełniające do nieestabilnego kodu brązowego pola ... Głównymi przyczynami są ukryte zależności (nie można wyciągnąć wszystkich dźwigni, aby uzyskać wyniki z kodu - nie można kpić scenariusze) i naruszenie zasady pojedynczej odpowiedzialności (testy są skomplikowane, wymyślone, wymagają zbyt dużej konfiguracji i są trudne do zrozumienia ).

Tymczasowo powiększyliśmy nasz zespół ds. Kontroli jakości (od jednej, może dwóch osób do pół tuzina lub więcej), aby przetestować platformę przed wydaniem. Był to niezwykle kosztowny pod względem czasowym i finansowym, niektóre wydania wymagałyby trzech miesięcy, aby ukończyć „testowanie”. Nawet wtedy wiedzieliśmy, że wysyłamy problemy, po prostu nie były to „programy blokujące” ani „krytyczne”, a jedynie „o wysokim priorytecie”.

Jeśli masz wieloletnie doświadczenie handlowe, docenisz to, że każda firma wykonuje zadania krytyczne , a następnie wynajduje wyższy poziom priorytetu powyżej tego, a najprawdopodobniej również jeden powyżej tego - szczególnie, gdy ktoś z góry naciska na funkcję / naprawę błędu. Robię dygresję ...

Z przyjemnością informuję, że ćwiczę TDD w mojej obecnej firmie (dom programowania, aplikacji internetowych i mobilnych) w połączeniu z Jenkins CI, aby przekazywać inne raporty analizy statycznej (pokrycie kodu jest najbardziej przydatne po potwierdzeniu pozytywnego wyniku testu) . Projekty, w których korzystałem z TDD, to system płatności i system obliczeń sieciowych.

Skok sprzedaży ...

Często może to być trudna walka uzasadniająca automatyczne testowanie dla nietechnicznych członków zespołu. Pisanie testów wciąga więcej pracy w proces programowania, ale ... czas, który zainwestujesz w testowanie teraz, pozwoli Ci zaoszczędzić na pracach konserwacyjnych później. Naprawdę pożyczasz czas . Im dłużej produkt jest używany, tym większe oszczędności - i pomoże to uniknąć dużego przepisywania .

Najpierw test oznacza, że ​​najpierw kodujesz swoją intencję, a następnie potwierdzasz, że kod ją spełnia. Zapewnia to skupienie i destyluje twój kod, aby robić tylko to, co jest zamierzone, i nie więcej (nie czytaj wzdęć). Jest to wykonywalna specyfikacja i dokumentacja jednocześnie (jeśli twój test jest dobrze napisany, a testy powinny być tak czytelne / czyste jak kod systemu, jeśli nie więcej!).

Nieprogramiści (często) nie mają tego wglądu, więc TDD nie ma dla nich dużej wartości i jest postrzegany jako jednorazowy skrót do wcześniejszej daty wydania.

Programowanie jest naszą domeną i według mnie to , jako profesjonalistów, naszym obowiązkiem jest doradzać w zakresie najlepszych praktyk, takich jak TDD. Menedżerowie projektów nie mogą decydować, czy zrobiono to w celu skrócenia czasu programowania, leży to poza ich jurysdykcją . W ten sam sposób nie mówią ci, z jakiej struktury, rozwiązania buforującego lub algorytmu wyszukiwania należy korzystać, nie powinni ci mówić, czy powinieneś stosować testy automatyczne.

W moim zdaniem przemysł rozwoju oprogramowania (na ogół) jest podzielona na obecne, fakt, że posiadanie testów dla oprogramowania nie jest normą.

Wyobraź to sobie w innych branżach: medycznej, lotniczej, samochodowej, kosmetycznej, miękkich zabawek, napojów alkoholowych itp. Poprosiłem moją narzeczoną o podanie branży, w której nie testują produktu, a ona nie może!

Być może niesprawiedliwe jest twierdzenie, że nie ma żadnych testów, ponieważ tak się dzieje ... ale w firmach bez testów automatycznych jest to proces bardzo ręczny / ludzki (czytaj niezgrabny i często podatny na błędy).

Jedną kwestię chciałbym podnieść w twoim pytaniu ...

Zazwyczaj chcieli, aby prace rozwojowe rozpoczęły się natychmiast lub po krótkim okresie projektowania. Bardziej zbliżony do Agile.

Będąc „Zwinnym” nie zaleca się przeprowadzania testów bez testów, pierwszym członkiem wymienionym na agilemanifesto.org jest Kent Beck , twórca XP i TDD!

Dwie książki, które gorąco polecam, jeśli interesuje Cię TDD lub po prostu ich nie czytałeś i jesteś zapalonym programistą (czy wszyscy dobrze to czytają?;)

Rosnące oprogramowanie zorientowane na ukierunkowane testy

Clean Code - seria Robert C. Martin („Uncle Bob”)

Te dwie książki wzajemnie się uzupełniają i łączą wiele sensu na kilku stronach.

Dzięki, że zadałeś to pytanie :)

Ci, którzy wdrażają klony. Nie mogę wymyślić lepszego procesu, kiedy trzeba coś opracować, który działa dokładnie tak, jak istniejący program.

Oczywiście jest to dość niezwykły przypadek, ale twórcy SQLite intensywnie korzystają z testów. (Zakładam, że ich proces rozwoju jest testowy, choć nie jestem pewien).

• 73 000 linii kodu
• 91 378 600 linii kodu testowego

Zobacz http://www.sqlite.org/testing.html