Debugging Sucks! Testing Rocks!

Tale članek sem se spravil pisat že dobro leto nazaj. Vmes sem tudi sformatiral disk in so šle stvari v tri … Kljub temu da je članek še vedno nedokončan sem se odločil da ga objavim, saj bo marsikomu v pomoč pri prvih korakih TDD-ja.

Prvi odziv programerjev ob omembi Test-Driven Developmenta je ponavadi negativen, saj pomislijo le na eno: “Tole mi bo pa vzelo dodatnih 50% več časa pri razvoju aplikacij.” Podoben odziv sem pred kratkim doživel pri “naših” programerjih, ko sem jim kazal kako naredimo “Acceptance Test” z uporabo Selenium RC-ja.^[1]
Zgornja trditev bi načeloma veljala samo če bi se življenski cikel aplikacije zaključil z prvo produkcijsko verzijo, ter ob klasičnem razvoju Dizajn-Implementacija-Testiranje^[2]. To zgodbo najverjetneje vsi poznamo:
“Imamo dva programerja, ki vsak zase nadgrajujeta svoj del že žive aplikacije. Ob združitvi kode, zgleda kot, da je vse ok. Čez čas dobita klic^[3], da določene stvari ne delajo, čeprav so prej delale. Vsak posebej za iskanje in razhroščevanje kode porabita polovico dneva.”
Take in podobne zgodbe so lahko preteklost. Rešitev je TDD.

Kaj je TDD

Test-Triven Development (TDD) je razvojna tehnika za softver. Z TDD tehniko stvari postavimo malce na “glavo”. Teste pišemo preden začnemo pisat implementacijsko kodo!. Test pelje oziroma diktira kodo ki se razvija.^[4]
TDD cikel pri razvoju aplikacij izgleda nekako takole:

• Dizajn: Pogruntamo kaj želimo narediti
• Test: Napišemo test, ki izraža naš dizajn.
  • Test ne bi smel uspeti – FAIL
• Implementacija: Napišemo kodo
• Test: ponovno
  • Test bi moral uspeti – PASS
• Refactoring po potrebi
• Ponavljaj

Še vedno vas je strah da bo več dela. Malce pa res. :)
Tri različne študije (Microsoft, IBM, John Deere / Ericsson) so pokazale:

• TDD projekti imajo dva krat večjo kvaliteto kode.
• Pisanje testov vzame le 15% več časa – dolgoročno gledano.
• Število hroščev in defektov je manjše za 40%.
• Skupinska produktivnost se poveča za 16%.

Testiranje

Kaj potrebuje testiranje?
- Backend: programska logika in ponovno uporabljene komponente
- Frontend: procesiranje form, templatov, bogata vsebina z uporabo “AJAX-a#, JSON, RSS Feed, Web Servisi

Kako testiramo?
- Backend: test funkcionalnosti programske logike z Unit Testi
- Frontend: “Acceptance” in Sistemski testi, ki se izvajajo na brskalniku, Testiranje RSS Feedov, Web servisov z Unit Testi, Kompatibilnostni testi …

Acceptance testing

je testiranje na določenem sistemu po principu “črne škatle“. Acceptance test zagotavlja da koda počna to kar želi “stranka”^[5], ne pa pričakovanj razvijalca! Temu testiranja bi lahko preprosto rekli tudi testiranje funkcionalnosti. Pa poglejmo kako implementirati Acceptance Test z “ubijalsko kombinacijo” PHPUnit in Selenium.

Priprave na testiranje

Zahteve:

• PHPUnit http://www.phpunit.de
• Testing_Selenium http://pear.php.net/package/Testing_Selenium
• Java 5 (1.5.0) je potrebna za Selenium RC http://java.sun.com
• Selenium Remote Control (RC) http://selenium.openqa.org/
• Xdebug^[6] če želimo informacije o “Code Coverage” http://www.xdebug.org

V tem članku uporabljamo PHPUnit, kateri od verzije 3.0 naprej, vsebuje PHPUnit_Extensions_SeleniumTestCase razred, katerega lahko uporabljamo za definicijo Acceptance testov. Sam razred pa za opravljanje testov potrebuje Selenium Core. Zelo pomembno je, da ne pozabimo da to NI Unit testiranje. PHPUnit je knjižnica za “Unit Testing”, med drugim pa je framework prav tako uporaben za integracijske ter acceptance teste.

Inštalacija PHPUnit:
Priročnik PHPUnit-a priporoča inštalacijo frameworka z uporabo PEAR Installer-ja. PEAR kanal (pear.phpunit.de), kateri se uporablja za distribucijo PHPUnit-a bora biti registriran z lokalnim PEAR okoljem.^[7] Ko to enkrat naredimo, uporabimo PEAR za inštalacijo paketa od PHPUnit kanala.

Inštalacija PHPUnita
PHPUnit dokumentacijo za Selenium najdete na http://www.phpunit.de/pocket_guide/3.2/en/selenium.html. Sedaj nam preostane še da iz PEAR kanala inštaliramo Testing_Selenium paket, ki ga potrebuje PHPUnit Selenium podaljšek.



Inštalacija paketa Testing_Selenium

Selenium:
je paket orodij za avtomatsko testiranje spletnih aplikacij. Vsebuje kar nekaj paketov, med drugim Selenium Core, Selenium RC, Selenium IDE, … Selenium Core opravlja aktivnosti uporabnika, izvaja test in obvešča o rezultatih testa. Selenium RC je dodatni serverski proces, ki ga rabimo, če želimo izvajati teste z PHPUnit podaljškom za Selenium. Njegov glavni namen je da omogoča izbranemu programskemu jeziku interakcijo z Selenium Core ki laufa na brskalniku z uporabo preprostega HTTP GET klica do RC strežnika. Komplicirano?!
Najnovejši Selenium RC dobite na http://selenium-rc.openqa.org/download.html. Po tem ko raspakiramo paket v njem najdemo kar nekaj map. V eni izmed njih je Selenium server, ostali so client driverji za različne programske jezike. Mi smo ga za PHP že inštalirali preko PEAR instalerja. Selenium RC zaženemo preprosto iz command lina:

java -jar selenium-server.jar -interactive

Še prej pa smo seveda inštalirali Javo. :)

Inštalacija Xdebug-a:
Xdebug je podaljšek za PHP, ki primarno služi za “debugging” – razhroščevanje kode, pri čemer je sposoben navrčt celo paleto koristnih informacij. Zna pa še narediti profil – “profiling” skripte in analizo pokritosti kode – “code coverage analysis”. Prav slednjo zadevo bomo pokazali v našem članku. Velja si zapomniti, da Xdebug ni potreben za izvajanje testov in da ga ne morete imeti naloženega skupaj z Zend Debuggerjem.
Najlažje je Xdebug inštalirati preko PEAR/PECL kanala.

pecl install xdebug

V php.ini dodamo tole klobaso^[8] za temeljit izpis informacij, remote debugging ter profiling na triger:

[Xdebug]
zend_extension="/opt/local/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so"
;General
xdebug.default_enable=On
xdebug.show_exception_trace=Off
xdebug.show_local_vars=1
xdebug.max_nesting_level=50
xdebug.var_display_max_data=3072
xdebug.var_display_max_depth=12
xdebug.dump_once=On
xdebug.dump_globals=On
xdebug.dump_undefined=On
xdebug.dump.REQUEST=*
xdebug.dump.SERVER=REQUEST_METHOD,REQUEST_URI,HTTP_USER_AGENT
xdebug.collect_params=4
xdebug.collect_includes=On
xdebug.collect_return=On
xdebug.show_mem_delta=On

;Remote debugging
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"

;Profiling
; Turns it off by default
xdebug.profiler_enable=0
; Turns xdebug on when ?XDEBUG_PROFILE=true is in GET or POST
xdebug.profiler_enable_trigger=1
; Your output directory - you'll eventually point webgrind at this
xdebug.profiler_output_dir="/tmp"

O samem orodju podrobno kdaj drugič. Gremo nazaj na testiranje.

Pisanje in zagon acceptance testov

Osnovna forma za acceptance test z PHPUnit in Selenium RC je zelo preprosta.

/** PHPUnit_Extensions_SeleniumTestCase */
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class MonetaOrderTest extends PHPUnit_Extensions_SeleniumTestCase
{
    protected function setUp()
    {
        /**
         * '*firefox' => Firefox 1 or 2
         * '*iexplore' => Internet Explorer (all)
         * '*custom /path/to/browser/binary => Other browsers (incl. Firefox on Linux)
         * '*iehta' => Experimental Embedded IE
         * '*chrome' => Experimental Firefox profile
         */
        $this->setBrowser(*firefox /Applications/Firefox2.app/Contents/MacOS/firefox-bin);
        $this->setBrowserUrl(http://gateway.home.internet-solutions.si);
    }

    /**
     * Test if
     * label First Name exists
     * element firstName exists
     *
     */
    public function testFirstNameExists()
    {
        //open test/moneta
  	$this->open(http://gateway.home.internet-solutions.si/test/moneta');
  	/** First Name */
  	//label exist
        try {
            $this->assertEquals("First Name", $this->getText("//form[@id='moneta']/dl/dt[1]/label"));
        } catch (PHPUnit_Framework_AssertionFailedError $e) {
            array_push($this->verificationErrors, $e->toString());
        }
        //element present
        $this->assertTrue($this->isElementPresent("firstName"));
    }
}

Metoda setUp() se uporablja za “zagon” testa. Tukaj definiramo kateri brskalnik se naj koristi. Firefox je le ena od možnih opcij. V primeru da Selenium RC ne vsebuje privzete reference za vaš priljubljeni brskalnik^[9] lahko uporabite prefix “*custom” pri kateremu določite pot do vašega izbranega brskalnika. Metoda setBrowserUrl() nastavi URL iz katerega potekajo vsi testi.

Če vas zanima še kaj o test driven developmentu me kontaktirajte.

Happy blogging(coding)!

1. podrobno bom predtavil testiranje z Selenium RC v današnjem članku [↩]
2. če je sploh kaj testiranja pred produkcijo [↩]
3. ponavadi od stranke, katero pa opozorijo uporabniki [↩]
4. Sedaj vemo od kod ime Test-Driven Development [↩]
5. uporabnik, brskalnik [↩]
6. opcijsko – ni pogoj za izvajanje testov [↩]
7. predvidevajmo da imate PEAR že inštaliran [↩]
8. v njej prilagodite pot do podaljška [↩]
9. v kar dvomim ;) [↩]

Sorodni zapisi:

• Enostavno je težje
• Zgodila se je prva slovenska PHP konferenca
• Zend Studio 6.0.1 installer na Ubuntu-ju 8.04 ga biksa
• Kako iz nule inštalirati Apache 2.2.8, MySQL 5.0.51 in PHP 5.2.5 na Ubuntu Dapper (6.06)
• Creatoor išče programerje