Temat: agile test driven development
Ha!
Wojtku, jak najbardziej się z tobą zgadzam! Chciałbym mieć klientów który rozumieją ideę TTD. 99% moich klientów nie rozumie co to jest test jednostkowy, a już na pewno nie trawi pozycji w kosztorysie pod tytułem testy jednostkowe - które zazwyczaj opiewają na ok 30% czasu potrzebnego na produkcję. Po długotrwałym tłumaczeniu co to jest - klient zadaje pytanie - czy ma wsparcie poprodukcyjne? Czy w ramach tego wsparcia poprawiamy błędy w oczywisty sposób mijające się ze specyfikacją? Jeżeli słyszy 2 razy tak - to mówi że on tych testów do szczęścia nie potrzebuje. Że jego strona/portal/serwis będzie działać i bez tego, a jak będzie chciał coś zmieniać - to od tego ma agencję by ogarniała temat.
Można uzasadnić klientowi korporacyjnemu że to jest niezbędne, ale tylko i wyłącznie dzięki temu że na spotkanie zaprasza się ich IT. Gorzej gdy oni nie uważają testów za potrzebne.
Kolejny aspekt testów jednostkowych - w testach też mogą być błędy - w końcu to taki sam kod który w różnych okolicznościach może mieć bugi.
Jak uzasadnić klientowi - że po jednym sprincie dostaje on np funkcjonalność rejestracji użytkownika w portalu, w tym samym tygodniu w projekt wkracza spec od usability i stwierdza że w tym formularzu powinno być o połowę mniej pól. Zaś w drugim kroku rejestracji - o połowę więcej? Mamy do przebudowania niewielki kawałek aplikacji, ale zdecydowanie większy w testach.
Dokumentacja - ilu ogólne dostępnych programistów będzie przegryzać się przez testy zamiast po prostu przeczytać dokumentację API ?
Kolejny aspekt programistyczny już - zawsze stosuję MVC. W tym w kontrolerze - zawsze atomizuję akcje. Czyli żadna akcja w żadnym kontrolerze nie robi 2 rzeczy na raz. Czas potrzebny na debug takiej akcji - jest stosunkowo krótki. Albo akcja działa - albo straszy błędem. Co zmienią w tej sytuacji testy? Nic. Wydłużają jedynie czas produkcji. Zaznaczam ze bardzo dokładnie kontroluję każde dane wprowadzane przez użytkownika - więc od tej strony nie ma co się zepsuć.
Testy regresyjne - nie są mi do szczęścia potrzebne. Pamiętaj że w agile z założenia oddajemy co sprint mały pakiet w pełni działających funkcjonalności - więc nie jest konieczne testowanie w połączeniu z czymś co pisaliśmy 10 sprintów wcześniej - po prostu dostarczony pakiet jest niezależny od tego co pisaliśmy wcześniej.
Jasne ze są projekty w których to co mówisz ma rację bytu, gdzie obsługujemy np sektor finansowy, a przez 10 sprintów budujemy współzależny pakiet funkcjonalności, działający na transakcjach i rozproszonych usługach, zintegrowany dla pełni szczęścia z kilkoma starszymi systemami posiadanymi przez instytucję. Wtedy - nie podejmę się takiego projektu bez pisania kompletu testów, pięknej dokumentacji, oraz sztabu analityków do pomocy. Tylko wiesz co? Taki projekt pisałem raz w życiu, gdy pracowałem dla centralwings przy ich systemie rezerwacyjnym, który musiałem integrować z światowym, oraz udostępnić dla rzeszy resellerów, z obsługą płatności włącznie. Wiesz co? Z powodu tego jednego razu - nie ma sensu wprowadzać czysto korporacyjnych rozwiązań do robienia czegoś mniej więcej prostego. Bo najczęściej jest to sztuka dla sztuki - bez wartości biznesowej, gdyż dla każdego z moich klientów kluczowym elementem jest czas.
пропозиції роботи
