Zwinny bez testów jednostkowych

27

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ć.

Zły Ropucha
źródło
14
Agile ma znacznie większą szansę na sukces dzięki zautomatyzowanym testom, które to potwierdzą. Musiałem wcześniej zastosować Agile bez testów i to pułapka. Jest to po prostu wygodny sposób na akumulację długu technicznego szybciej niż wcześniej.
MetaFight
5
TDD niekoniecznie jest jedyną praktyką, która Cię tam zabiera. Jest to jednak powszechne. Osobiście uważam BDD za bardziej pragmatyczne podejście.
MetaFight
6
„Zwinne ma znacznie większą szansę na sukces dzięki zautomatyzowanym testom, które je wspierają”: podobnie zresztą jak projekty nie zwinne. Myślę, że automatyczne testowanie jest raczej ortogonalne w stosunku do zastosowanej metodologii: daje ci większą pewność, że kod jest poprawny i pomaga utrzymać go w czystości.
Giorgio
Przy okazji tego pytania mieszany test jednostkowy i TDD możesz mieć test jednostkowy bez TDD.
Walfrat,
Czytając tutaj odpowiedzi, jestem zaskoczony, jak wiele rzeczy się zmieniło, odkąd nauczyłem się zwinności w połowie XX wieku. Programowanie TDD i par zostały uznane za zwinne praktyki ESSENTIAL do utrzymywania wysokiej jakości kodu w szybkim tempie.
nomen

Odpowiedzi:

37

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.

Gumowa kaczuszka
źródło
Czy musisz postępować zgodnie z Manifestem Zwinności, aby być zwinnym?
JeffO
Nie @JeffO. Ty nie, ale to z pewnością pomaga. Zredagowałem, aby wyjaśnić mój zamiar.
RubberDuck,
1
IMO najbardziej zwinnymi programistami są ci, którzy są bardzo pragmatyczni, chociaż nigdy nie słyszeli o zwinnym manifeście.
Giorgio
1
Nie mogę się z tobą nie zgodzić @Giorgio. Byłem w zwinnym zespole wiele lat, zanim ktokolwiek z nas usłyszał o Agile.
RubberDuck,
2
@CortAmmon - Jeśli chcesz zdefiniować Agile (duża zwinność „A” jak w twojej metodologii), zgodziłbym się z tobą, ale jeśli chcesz być zwinny (trochę „a” jak w byciu zwinnym, aby lepiej radzić sobie ze zmianami ), nie musisz wcale stosować żadnej konkretnej metodologii. Jeśli potrafisz robić wodospad i nadal radzić sobie ze zmianami (trudne, ale nie niemożliwe), kogo to obchodzi?
JeffO
30

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.

David Arno
źródło
4
Trudno zobaczyć, jak zespół może utrzymywać działające oprogramowanie w dowolnym środowisku bez testów.
Bryan Oakley
6
To, że coś jest trudnego do zobaczenia, nie uniemożliwia
Ampt
8

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.

Axel
źródło
3
Możesz to przetestować ręcznie. Nie potrzebujesz do tego testów jednostkowych. Oni pomagają. DUŻO. Są jak najlepsze rzeczy, które mogą poprawić proces. Ale w żadnym wypadku nie są niezbędne do dostarczania oprogramowania.
T. Sar - Przywróć Monikę
Tak oczywiście. Nie powiedziałem, że nie możesz tego zrobić ręcznie. Powiedziałem jakikolwiek test. Nie testowałem żadnych form niezgodności. A jeśli chodzi o ręczne testowanie, to z innej perspektywy, jak możesz zachować zwinność w obliczu regresji.
Axel
Rozumiem twój punkt widzenia. Pytanie dotyczy jednak testów jednostkowych w testach specjalnych, a nie dokładnie testów w ogóle. Czytanie odpowiedzi w kontekście pytania powoduje, że testowanie uznaje się za „test jednostkowy”!
T. Sar - Przywróć Monikę
Przepraszam za to.
Axel
2
@ThalesPereira, test jednostkowy, który mówi ci, czy zmiana, którą dokonałeś czterdzieści sekund temu, że coś złamała, jest o wiele bardziej zwinny niż raport otrzymany z działu kontroli jakości, który mówi, że coś, co ktoś zmienił trzy dni temu, złamał to.
Solomon Slow
2

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!

gbjbaanb
źródło
Możesz uruchomić zwinny proces tylko z testami integracji. Czy to jest teoretyczne czy mówione z doświadczenia?
R Sahu
1

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.

JeffO
źródło
1

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ć.

Niels van Reijmersdal
źródło
1
w rzeczywistości nie musi to być „test jednostkowy”, wystarczy uruchomić test integracyjny i uznać, że to wystarczy. Jeśli jednak nic nie masz i wszystko testujesz ręcznie, najprawdopodobniej spowolnisz szybkie reagowanie na zmiany lub dostarczysz całkiem sporo regresji.
Walfrat,
2
Uzgodnione technicznie, że tak nie jest, ale testy na wyższych poziomach są często bardziej kruche, trudniejsze w utrzymaniu i prawdopodobnie spowalniają cię w końcu, jeśli masz ich wiele. Podoba mi się to, jak ujmuje to Martin Fowler: „Jeśli wystąpi błąd w teście wysokiego poziomu, nie tylko masz błąd w kodzie funkcjonalnym, masz również brakujący lub niepoprawny test jednostkowy”. from martinfowler.com/bliki/TestPyramid.html
Niels van Reijmersdal
Test na wyższym poziomie nie testuje tych samych rzeczy, więc pozwalasz na dziury, ale uważasz, że obecnie ryzyko jest wystarczające. Dla niektórych stron internetowych, które mogą wystarczyć, dla krytycznego systemu finansowego -> nie ma mowy.
Walfrat