Zwinny bez testów jednostkowych

Czy ma sens mówienie o „zwinnym programowaniu” lub twierdzeniu, że stosujesz „zwinną metodologię”, jeśli baza kodu, nad którą pracujesz, ma 0% zasięgu testu jednostkowego? (A ty jako zespół nic z tym nie robisz).

Wyjaśnij: dla mnie to nie ma sensu. Z mojego osobistego doświadczenia wynika, że ​​testy jednostkowe są jedynym narzędziem, które pozwala naprawdę być „zwinnym” (tj. Reagować na zmiany, ulepszać projekt, dzielić się wiedzą itp.), A TDD jest jedyną praktyką, która Cię tam prowadzi .

Może istnieją inne sposoby, ale wciąż nie widzę, jak mogą one działać.

Aby być pedantycznym, nic w Manifeście Agile ani w Przewodniku Scrumowym nie zawiera żadnych odniesień do praktyk technicznych, takich jak testy jednostkowe lub TDD. Więc tak, teoretycznie możesz dostarczać wcześnie i często z naciskiem na współpracę i wartość bez nich i nazywać się Zwinnym, możesz nawet mieć sprawność .

W praktyce jednak prawie niemożliwe jest konsekwentne dostarczanie wartości ( do produkcji ) co kilka tygodni bez dobrego zestawu testów. Obejmuje to testy integracyjne, a także testy jednostkowe. Testy jednostkowe idą tylko tak daleko. Jest powód, dla którego jest to piramida, a nie prostokąt.

Bez testów jako siatki bezpieczeństwa albo wprowadzisz wiele błędów regresji w każdym wydaniu, albo będziesz przerażony refaktoryzacją. Oba będą miały duży wpływ na twoją zdolność do kontynuowania w zrównoważonym tempie. Jeśli nie możesz utrzymać tempa lub zmienić kursu (przeprojektować) w razie potrzeby, nie masz zręczności. Zwinność to przecież cel, do którego dążymy.

Zwinny manifest po prostu stwierdza:

Osoby i interakcje dotyczące procesów i narzędzi

Działające oprogramowanie w obszernej dokumentacji

Współpraca z klientami w zakresie negocjacji umów

Reagowanie na zmianę po wykonaniu planu

Brak wzmianki o testach jednostkowych. Nawet 12 zasad nie wspomina o testowaniu.

Tak więc technicznie można być zwinnym zespołem bez pisania testów jednostkowych. W praktyce jednak naprawdę trudno jest zobaczyć, jak zespół może utrzymywać działające oprogramowanie w zwinnym środowisku bez testów pomagających w dokonywaniu ciągłych zmian.

Mimo że nie ma bezpośredniego słowa o testowaniu jednostkowym, TDD lub jakimkolwiek teście w zwinnym manifeście, tak jak inni tutaj odpowiedzieli, uważam, że dobry Scrum Master lub Deweloper byłby w stanie rozpoznać jedno ze stwierdzeń w manifeście.

Działające oprogramowanie  w obszernej dokumentacji.

Skąd ktokolwiek mógłby wiedzieć, czy oprogramowanie działa? Manifest nie musi wyraźnie określać terminu testowanie. To jest zwięzłe.

Testowanie jednostkowe (w kontekście tematu) spowolni fazę kodowania na wcześniejszym etapie, ale będzie tego warte w miarę postępów, przyspieszając rozwój. Zapewnia to dokładną kontrolę ziarnistości podczas testowania na poziomie kodu, a także sprawia, że ​​projekt jest skalowalny, co daje pewność, że oprogramowanie działa i może łatwo obsługiwać regresję; do którego sprawi, że twój rozwój będzie zwinny.

To absolutnie ma sens. Zwinność nie polega na testowaniu, jak już wspomnieli inni, ale na konkretnej odpowiedzi na twoje pytanie:

Nie, wcale nie potrzebujesz testów jednostkowych.

Możesz uruchomić zwinny proces tylko z testami integracji. Możesz na przykład przeprowadzić automatyczny test integracji co noc i naprawić błędy, które zostaną wykryte następnego dnia. Jeśli chcesz, możesz mieć ręczny tester do ciągłego testowania integracji. Niezależnie od systemu testy jednostkowe są całkowicie opcjonalne.

Może się okazać, że testy jednostkowe pomagają ci się rozwijać i są wystarczająco sprawiedliwe, ale istnieje wiele rzeczy, które mogą pomóc w rozwoju, których możesz nie mieć.

Potrzebujesz jednak jakiejś formy testowania, nawet jeśli są to stare „beta-testy klientów”. Jeśli Twój klient jest mocno zaangażowany w proces i nie ma nic przeciwko znajdowaniu błędów, może to działać - ponieważ mają tendencję do znajdowania błędów, o których nikt inny nawet nie pomyślał, że są błędami!

To nie jest wymagane. Testowanie jest świetne, gdy masz ludzi, którzy naprawdę wiedzą, jak go używać. Kiedy tego nie robisz, nie tylko nie jest to konieczne, staje się zobowiązaniem. Powiedziałbym, że jest wielu programistów, którzy nie są w tym zbytnio wykwalifikowani.

Cieszę się, że potwierdziłeś w swoim pytaniu, że zwinność polega na tym, jak faktycznie wypuszczasz oprogramowanie zamiast postępować zgodnie z jakąś metodologią. Manifest zwinny jest dobrym odniesieniem, ale nie jest to ostateczny przewodnik. Zwinność istniała wcześniej. Istnieją sposoby opracowywania oprogramowania, które zapewni „większą zwinność”, ale w różnych projektach można stosować różne kombinacje.

Jeśli wypuszczasz nowe oprogramowanie w tempie akceptowanym przez klienta, prawdopodobnie jesteś zwinny. Chciałbym również uwzględnić brak zbytniego wypychania i narzekanie na zmiany funkcji przez programistów. Naprawianie jednej rzeczy tylko po to, by złamać inną, też nie jest idealne. Gdy użytkownik ma kilka wersji opóźnionych w aktualizacji, prawdopodobnie nie jest zbyt zwinny, niezależnie od tego, czy testuje.

Chciałbym przeciwstawić się (innym odpowiedziom), że manifest Agile wyraźnie mówi coś na ten temat, a mianowicie:

Ciągła dbałość o doskonałość techniczną i dobry design zwiększają zwinność.

Bardzo podoba mi się definicja doskonałości technicznej LeSS, która obejmuje testy jednostkowe i TDD. Teraz możesz argumentować, że możesz nie potrzebować testów jednostkowych i / lub TDD, aby to osiągnąć, ale jest to najczęstszy i prawdopodobnie zalecany sposób.

Zwinność organizacyjna jest ograniczona przez sprawność techniczną

Innymi słowy, kiedy powolnie wprowadzasz zmiany w swoim produkcie, nie ma znaczenia, w jaki sposób tworzysz zespoły, organizację lub jakie ramy przyjmujesz, powolnie reagujesz na zmiany.

Jeśli możesz zapobiec temu, by Twój produkt opierał się zmianie w inny sposób, możesz być na dobrej drodze, ale:

Wynalazłem programowanie ekstremalne, aby świat był bezpieczny dla programistów. - Kent Beck

Scrumowi brakuje jakichkolwiek praktyk technicznych, ale Jeff powiedział o tym:

Nigdy nie widziałem nadproduktywnego zespołu Scrumowego, który nie stosowałby praktyk programistycznych Extreme Programming. - Jeff Sutherland

Cytat z tego artykułu: http://ronjeffries.com/articles/017-02ff/gathering2017/

Oczekiwałbym, że zespoły Scrum bez praktyk technicznych w końcu, stosując retrospektywy, wymyślą podobne praktyki. Chcesz też być nadproduktywny, prawda?

Model płynności Agile wspomina o nim na poziomie dwóch gwiazdek:

Przydatne techniki obejmują ciągłą integrację, rozwój oparty na testach , programowanie par i własność zbiorową.

Jeśli celujesz tylko w pierwszy poziom płynności Agile, możesz pominąć praktykę, ale każdy większy i dłużej działający produkt powinien przynajmniej spróbować osiągnąć poziom dwóch gwiazdek.

Zatem ogólny konsensus jest taki, że bez dobrych testów jednostkowych, czystego kodu i praktyk refaktoryzacyjnych, obecnie nie jest możliwe, aby być naprawdę zwinnym. To może się zmienić w przyszłości, gdy pojawią się nowe praktyki techniczne.

Jak myślisz, jaka byłaby odpowiedź, gdybyśmy zapytali kilku sygnatariuszy manifestu, takich jak Robert C. Martin, Martin Fowler lub Kent Beck? Może powiedzą, że to zależy, ale ogólnie jest to coś, co powinieneś zrobić.