Ciągła integracja + testy automatyczne przy pomocy Selenium i Hudson (Jenkins)

Od zawsze programiści marzyli o produkcji oprogramowania bez jego pisania :-)
Niestety o ile programiści dalej sobie marzą o tym,
ich koledzy teserzy, psujący dzieła programistów mają do wyboru automaty do testowania.

Automatyczne testowanie jest jednym z głównych postulatów eXtreme Programming (XP). Automatyzacja polega na użyciu oprogramowania do sterowania wykonaniem testów, porównywania ich wyników z oczekiwanymi, czy raportowania.

W dobie zaawansowania dedykowanych aplikacji internetowych i pozornie prostych w budowie systemów aukcyjnych oraz sklepów interenetowych, wymagania stawiane testerom stale rosną. Od testerów wymaga się podstawowych zdolności programistycznych, zwłaszcza, gdy używa się narzędzi testujących w sposób automatyczny.

Gdyby nie Selenium oraz Hudson / Jenkins testerzy stali by się w sposób naturalny świetnymi programistami. Na szczęście mogą nadal skupiać się na testowaniu jakości i zwracaniu uwagi na dziwne i "na niby bezpieczne" rozwiązania. Poniżej wyjaśnię na czym polega trick ;-)

Wszystko zaczyna się od zmiany podejścia i zastosowania:

• pomysłodawcy funkcjonalności powinni myśleć o optymalnych krokach możliwych do wykonania w produkcji, które można w zrozumiały sposób przetestować - bez budowania wzmocnionych mostów dla testerów, gdy potrzebujemy wykonać funkcjonalnie kładkę :-)
• TDD - programowanie ukierunkowane testami (Test-Driven Development) opierające się na technice automatycznego testowania, zaczynając od testu wynikającego ze specyfiki funkcjonalności, po czym realizowanie małymi krokami funkcjonalności, aby zapewnić poprawne wykonywania testu
• ciągłej integracji - po każdej zmianie, raz na wydanie, ciągle w repozytorium SVN/trunk lub GIT/master wykonywanie testów automatycznych, analizy statycznej kodu oraz wszelkich weryfikacji wykrywających
• reagownie na zmiany i błędy w trakcie procesu tworzenia a nie tylko incydentalnie po wydaniach
• świadome myślenie o lawinowym charakterze strat, gdy błąd który można usunąć w trakcie produkcji znajdzie klient po wydaniu wersji
• automaty służą do testów systemowych i integracji całości systemu a nie tylko, aby sobie budowały w nocy kod tak dla draki; aby ktoś z jakiegośtam działu nie zepsuł pracy kogoś z któregoś tam działu :-)

Tak mi się wydaje, że dopiero po uświadomieniu w drużynie projektowej od biznesu po produkujących kod, dlaczego warto automatyzować testy można przejść do zabawy z Selenium IDE, Selenium RC oraz Hudson ew. Hudson. Cytuje mądrą wypowiedź znawców kontroli jakości:

Ciągła integracja to przede wszystkim sztuka szybkiego przepływu informacji w procesie produkcji. Im szybciej wiemy o problemie, tym więcej czasu i za mniejsze pieniądze zareagujemy. Im później, tym większe ryzyko.

Materiały: http://www.thinkvitamin.com/features/webapps/easy-automated-web-application-testing-with-hudson-and-selenium

http://agilesurfing.pl/2011/programowanie/automatyczne-testowanie-kodu-jak-to-robic/

http://test-driven-development.com/