Cieszę się, że technologia Flex i sam jezyk ActionScript wdziera się do rozwiązan korporacyjnych na tyle szybko, że coraz częsciej zespoły wytwarzające oprogramowanie w oparciu o Flexa, stosują znane metodyki programowania używane w innych srodowiskach/technologiach wytwarzania od dosyć dawna. Same przez siebie niejako nobilitują one Flex’a, pokazując, ze jest on w stanie podołać skompilkowanym wdrożeniom RIA, absorbującym duże zespoły projektowe i produkcyjne (mam tu na mysli 30-40 osób). Automatyzacja jest teraz na czasie, w tym zagadnienia dot. automatyzacji refaktoringu, czy testowania – dla kogos z pozoru być może są to sprawy trywialne, niestety tak nie jest. Co to jest TDD (ang. Test Driven Devlopment)? – po krótce jest to wytwarzanie oprogramowania zorientowane na testy.

Pomysł na TDD, pojawił się niedługo po ukłuciu i rozpowszechnieniu się terminu XP (ang. eXtreme Programing), jednej z bardziej popularnych metodyk lekkich (inaczej zwanych zwinnymi ang. agile) wytwarzania oprogramowania, które kładą nacisk na dostarczanie klientowi artefaktów programowych, zamiast papierowych tj. dokumentacji – która w XP ma formę szczątkową w porównaniu m.in. do RUP (ang. Rational Unified Process), który czerpie korzenie z USDP (ang. Unified Software Development Process)) i jest reprezentantem metodyk ciężkich. XP jako uznana metodyka zwinna, zaczeła permanentnie dążyc do skracania faz produkcyjnych i tak m.in. powstał pomysł na to, aby zautomatyzowac testowanie poprzez wprowadzenie testów jednostkowych (nazwa bierze się z testowania danej jednostki, jaka jest metoda (funkcja) lub klasa) oraz przeniesienie fazy testowania na poczatek fazy implementacji, a docelowo zmusić programistę, aby pisał przypadki testowe przed napisaniem właściwego kodu aplikacji programowej, pisać na początku, co kod ma zrobić, a nie jak coś ma być zrobione. W porównaniu do tradycyjnego procesu wytwarzania oprogramowania, w którym testy (czy to weryfikacyjne, walidacyjne, wydajnościowe, czy to ilościowe) sa przeprowadzane za zwyczaj w koncowych fazach procesu wytwarzania oprogramowania, była to koncepcja nadzwyczaj rewolucyjna (nawet jak na poczatki XXI wieku ). Z ”marketingowego” punktu widzenia, wydawalo sie od razu, ze programisci będą mieć wiekszy zapał aby pisać testy na początku fazy wdrożenia, niż w kolejnych fazach (przecież na zdrowy rozsądek każdy z nas jak podchodzi do projektu ma najwięcej zaangażowania na początku prac, najmniej na żmudnym końcu, kiedy należy poprawiac i poprawiac, i nie zawsze wiadomo, gdzie się popełniło błąd ), a kod tworzony wedle ścisłych reguł umożliwiajacych automatyzację testowania oraz przypadków testowych będzie łatwiejszy w pielęgnacji i rozbudowie.

Nie ma co się oszukiwać, TDD sprawdza się dobrze przede wszystkim w duzych projektach, dotyczy to takze Flex’a, w małych m.in. programiści nie rozumieją po co mają pisać “nadmiarowy kod” testujący coś, co po prostu “musi działać”  - jednym slowem stosowanie TDD w malych projektach bardziej prowadzi do frustracji niż jest pomocne. Ale przecież to m.in. za sprawa Flex’a – technologia Flash wchodzi pod strzechy rozwiazań korporacyjnych, gdzie takowe metodyki się sprawdzają. Kod testuje siebie, o to własnie chodzi, i dlatego też powstał FlexUnit , czy ASUnit. Obecna wersja np. FlexUnit, czyli 0.85 jeżeli chodzi o stosowanie metodyki TDD sprawdza się bardzo dobrze, tym bardziej jezlei ktos stosowal JUnita (Java) w Eclipsie, nie bedzie mial za duzo problemow z przesiadka ;)

Chcąc zabrać się za TDD we Flex, musisz wpierw zrozumiec co to jest test jednostkowy, asercja i przypadek testowy i troche zmienic swoj tradycyjny punkt wytwarzania oprogramowania ;) – sam wiem, po sobie, ze potrzebowalem troche czasu, aby przywyknąć. Polecam artykuł Neil’a - Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0 - zrobil na prawde dobra robote przedstawiajać to zagadnienie w dosyc zwiezly sposob, czego ja bym nie potrafił ;) Warto też zapisać się na listę dyskusyjną FlexUnit - http://groups.google.com/group/as3flexunitlib.

Przepraszam, za ten przydługi wpis, ale jedno jest pewne, mówie to z własnego doswiadczenia, jeżeli macie duży projekt RIA, spróbujcie stosować TDD, a zobaczycie, że jego siła tkwi przede wszystkim w tym, że stosujac go, o wiele łatwiej jest zlokalizować “gdzie jest problem w kodzie”.

P.S. Miałem poruszyc w tym poscie BDD (ang. Behaviour Driven Development), czyli wytwarzanie oprogramowania zorientowane na behavioryzm, które jest niejako ewolucją TDD, i osobiście uważam, że jest przyszłością. W trakcie pisania tego postu zdecydowalem, ze bym Was juz całkiem zanudził z tym BDD, stad napisze o nim w innym poscie ;) – kiedys indziej, być może pokusze się o jakis tutorial, jako, że o stosowniu BDD we Flexie na razie w sieci dosyc mało informacji.