Słuchaj the Testing Goat!

SONY DSC

To zdjęcie powstało podczas rodzinnego spacerku ostatniego pogodnego dnia tej jesieni. Karmimy kózki w Karniowicach:) Uśmiałam się bo akcja natychmiast skojarzyła mi się z moją ostatnią aktywnością, dzięki której ćwiczę swoją systematyczność i dokładność, czyli zgłębianie tematu test-driven development (TDD). Posługują się w tym celu książką, którą poleciła mi Pewna Doświadczona w Temacie Osoba, czyli “Test-Driven Development with Python. Obey the Testing Goat: Using Django, Selenium and JavaScript”  autorstwa Harry’ego J. W. Percivala (https://www.obeythetestinggoat.com).  Póki co ucząc się skrupulatnie podążam za wskazówkami autora, ale gdy bardziej ogarnę temat będę się starała zastosować tę wiedzę do własnego, na początku choćby najmniejszego projektu.

Ogarnięcie tematu testów jest zazwyczaj juniorom zalecane. Faktycznie, bycie testerem wydaje się sensownym i co ważne realnym początkiem kariery w IT. Póki co starałam się o tym nie myśleć zbyt intensywnie, bo wizja ta, choć pragmatyczna, jest hm… mało urocza no i niezbyt nadaje się na motywację typu: “nie śpij po nocach, ogranicz wszystkie swoje aktywności do niezbędnego minimum, wysil wszystkie swoje komórki mózgowe, zwłaszcza te, o których istnieniu nie miałaś do tej pory pojęcia, zostań ninja w planowaniu czasu swojego i swojej rodziny, żyj w poczuciu, że robisz to kosztem najbliższych, bo w zamian… zostaniesz testerem:) Nie mam oczywiście nic przeciwko temu zajęciu, poza tym może na niektórych taka wizualizacja działa, ale na mnie po prostu nie. I kropka.

Ale zmobilizowałam się, ok, zobaczę o co w tym w ogóle chodzi. No i  oczywiście – zdziwiłam się. Po pierwsze tym, że tak naprawdę to też jest programowanie. I to w przypadku TDD konkretna filozofia programowania, która, o rety, do mnie trafia. Współgranie testów funkcjonalnych i jednostkowych, z których pierwsze patrzą z perspektywy użytkownika, dbają o to, by dać mu oczekiwaną wartość, a programiście pomagają w zaplanowaniu funkcjonalności aplikacji, z drugimi, które stopniowo pomagają te zamierzenia zrealizować – to ma sens! Podejście step-by-step przypomina zarządzanie w stylu agile, które zdążyło mi już przypaść do gustu i serca.

Ale, oczywiście, podążając za autorem wciąż się buntuję. No bo trzeba się wbić w straszny reżim, a ja tu jestem na etapie wymyślania sobie różnych projektów, dobierania do nich zagadnień, których w ten sposób się uczę lub ćwiczę (zatem im więcej na bieżąco pomysłów, tym lepiej), a tu nie, trzeba się trzymać tego co ściśle zaplanowane i ani kroku dalej. YAGNI! U mnie póki co wywołuje to ból, ale w komercyjnym świecie ma zapewne sens – nie powstaje niepotrzebny kod, więc nie marnuje się czasu, pieniędzy i energii programistów.  Zastanawia mnie jednak gdzie i jak jest określane to miejsce, w którym należy zastosować testy. W moim “podręczniku” testami objęte jest już zrobienie sobie kawy przed przystąpieniem do pracy:) Ale czy tak rzeczywiście ma być? Przecież pewne sprawy wydają się oczywiste, więc zajmowanie się nimi to jawna strata czasu, rzeczonych pieniędzy itp. Django na przykład ma, jak sądzę, dobrze opracowany system komunikowania błędów. Czy objęcie tych działań testami nie prowadzi do powstania zbędnych dubletów? I tak dalej…. Oj, wiele jeszcze do zrozumienia przede mną:) Cóż, wracam do książki słuchać meczenia mojej kózki:)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s