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ć.
unit-testing
agile
tdd
Zły Ropucha
źródło
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło
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!
źródło
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.
źródło
Chciałbym przeciwstawić się (innym odpowiedziom), że manifest Agile wyraźnie mówi coś na ten temat, a mianowicie:
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.
Jeśli możesz zapobiec temu, by Twój produkt opierał się zmianie w inny sposób, możesz być na dobrej drodze, ale:
Scrumowi brakuje jakichkolwiek praktyk technicznych, ale Jeff powiedział o tym:
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:
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ć.
źródło