3. Kas ir vienībtestēšana?
• Oficiāli:
– Metode, ko lieto atsevišķu programmatūras
koda daļu pārbaudei, vai tās darbojas
saskaņā ar specifikāciju.
– Testē mazāko iespējamo koda vienību
• klases metodi
• moduļa funkciju
• Vienkāršotā izpratnē
– Testi, ko raksta pats programmētājs
4. Galvenie mērķi
• Pārliecināties, ka
– kods dara to, kas paredzēts
– labojumi kodā (t.sk. refaktorēšana) nesabojā
kaut ko citu
• Uzlabot koda kvalitāti pirms integrācijas
testēšanas
• Padarīt kodu uzturamu arī citiem
• Automatizācija
5. Vienībtestēšana VS integrācijas
testēšana
• Vienībtesti nav integrācijas testi!
– Integrācijas testi apskata vairāku moduļu
sadarbību vai visu sistēmu kopumā
– Vienībtests pārbauda katru moduli atsevišķi
Vienībtests:
- vai šim vītnes
platums
visur ir vienāds?
http://www.bolt-manufacturer.com/picture/hex-bolts/heavy-hex-bolt.jpg
Integrācijas tests:
- vai ar šo var uzspiest līdz 45?
http://inhabitat.com/files/mowercycle23.jpg
6. Ko nozīmē "katru moduli
atsevišķi"?
• Vienībtestā jācenšas izolēt pārbaudāmo
moduli no citiem moduļiem
• Kļūdu gadījumā gribam zināt, kas tieši
vainīgs
• Lai izolētu no pārējiem moduļiem, lieto
imitācijas (mock) un aizbāžņus (stub)
saistīto moduļu vietā
7. xUnit
• xUnit: vienībtestēšanas ietvaru saime
dažādām valodām, kas
– izmanto programmatiskus testus
– lieto vienus un tos pašus jēdzienus
• Vēsturiski pirmais ir SUnit (SmallTalk unit
testing framework)
• Vēlāk arī JUnit (Java), CPPUnit (C++),
NUnit (.Net saimes valodas), PHPUnit.
8. xUnit termini
• Testu kopa (test suite)
– Atsevišķi testi, ko izpilda moduļa funkcionalitātes
pārbaudei
– Pārbaude kādam koda modulim (piemēram, klasei
DateTime būtu testu kopa DateTimeTest)
• Testpiemērs (test case)
– Tests, ko izpilda kādas funkcionalitātes pārbaudei
• Testa konteksts (test fixture)
– Datu/vides sagatavošana testu izpildīšanai
• Testu izpilde (test execution)
– Testu darbināšana dotajā kontekstā
• Apgalvojumi (assertions)
– Kodā pierakstāmi pieņēmumi, kam jābūt spēkā pirms/pēc
koda izpildes
• http://www.martinfowler.com/bliki/Xunit.html
9. xUnit testu kopas uzbūve
public class SomethingTest inerhits Test {
//sagatavošanās ('fixture')
public void SetUp() {
}
//savākšana aiz sevis
public void TearDown{
}
//paši testi
public void TestMethod1(){}
public void TestMethod2(){}
...
}
10. xUnit testu izpildes principi
• Meklē visas testu kopas
• Katrā testu kopā meklē visas metodes, kas
sākas ar "Test"
• Katrai šādai metodei izpilda:
SomethingTest->SetUp();
SomethingTest->TestMethod1();
SomethingTest->TearDown();
SomethingTest->SetUp();
SomethingTest->TestMethod2();
SomethingTest->TearDown();
11. Vienībtestēšanas maksimums
• Nopietnākais vienībtestēšanas lietojums –
testu bāzētā izstrāde (test driven
development)
– specificē moduļu interfeisus
– raksta testus, kas pārbauda šos interfeisus
– tikai tad sāk rakstīt pašu kodu
• Sākotnēji visi testi būs "izlaisti" vai "failed"
• Beigās būs strādājoša sistēma un 100%
veiksmīgi testi
15. PEAR: kas tas tāds?
• PEAR: PHP Extension and Application
Repository
• Ideja: komdandrindas rīks, kas ļautu instalēt
PHP paplašinājumus
• Uzlikšana:
1. iedarbina PHP komandrindas interfeisu
2. lejuplādē http://pear.php.net/go-pear.phar
3. php go-pear.phar
4. pārstartē tīmekļa serveri
• Var gadīties, ka noder
pear upgrade --force PEAR
16. Kas ir Xdebug?
• PHP ir skriptēšanas valoda, tas izpildās
kāda procesa ietvaros (tīmekļa serverī,
komandrindā)
– "klasiska" atkļūdošanas pieeja, kur pieslēdzas
procesam, būtu sarežģīta
• Xdebug ir PHP modulis, kas
– darbojas PHP interpretatora iekšienē
– uz ārpusi sniedz atkļūdošanas informāciju
– darbojas kā HTTP serviss
17. XDebug uzlikšana
• Xdebug ir PECL modulis
• Instalējams ar PEAR/PECL:
– pecl install xdebug
• Ini failā papildus:
[xdebug]
zend_extension=/Applications/XAMPP/xamppfiles/lib/php/php-
5.3.1/extensions/no-debug-non-zts-20090626/xdebug.so
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
18. PEAR uz XAMPP/Wamp
• XAMPP
– Jaunākās versijas ir ar PEAR,
– Xdebug jāinstalē pašiem
• WampSever
– Vecākās versijās PEAR var būt jāliek pašiem
– Xdebug vajadzētu būt
19. Xdebug atbalsts
• NetBeans – kopš 6.versijas integrēts
atbalsts
• Notepad++ var iekonfigurēt:
– http://dowdrake.com/showthread.php?343-
Xdebug-with-WAMPServer-and-Notepad
23. PHPUnit + ietvari?
• Zend
– Atbalsts jau iekļauts ietvarā
– http://framework.zend.com/wiki/display/ZFDEV/Testing+St
andards
• CodeIgniter
– Atbalsta ietvarā nav (ir slikts), ir 3. puses risinājums
– http://jensroland.com/projects/toast/
• (nav PHPUnit, bet esot labs)
– https://bitbucket.org/kenjis/my-ciunit/overview
– https://gist.github.com/1142213
• Symfony
– Ir spraudnis: http://www.symfony-
project.org/plugins/sfPhpunitPlugin
25. Failu struktūra
• Labā prakse ir katru (īstā) koda klasi likt
atsevišķā failā
• Katrai klasei "atbilst" ir sava testu kopa
• Tipisks risinājums: saknes katalogā veidot
apakškatalogu "tests" ar līdzīgu struktūru
īstajai
/
/common_includes /test
/database
/exporters /common_includes
/test /database
/exporters
26. Testa kopas struktūra
<?php
class ManaKlaseTest extends PHPUnit_Framework_TestCase {
protected $object; //testējamās klases instance
protected function setUp() {
$this->object = new ManaKlase();
}
protected function tearDown() {
unset($this->object);
}
public function testMetodesPasauksana() {
$this->object->PasauktMetodi();
$this->assert...();
}
27. Ko rakstīt testpiemēros
• Katrai metodei raksta vienu vai vairākus
testpiemērus
• Testpiemērs pasauc kādu funkciju un fiksē
apgalvojumus, kam jābūt spēkā pēc
izsaukšanas
• Labais stils – viens apgalvojums uz vienu
testpiemēru
28. Apgalvojumu veidi
• visi apgalvojumi ir
PHPUnit_Framework_TestCase metodes.
Tāpēc $this->assert..
• assertEquals(what1, what2);
• assertTrue(), assertFalse()
• assertGreaterThan(); assertLessThanOrEqual();
• assertStringStartsWith(); assertSelectRegexp();
• + daudz citu:
http://www.phpunit.de/manual/3.6/en/writing-tests-for-
phpunit.html#writing-tests-for-phpunit.assertions
29. Atkarības
• Var gadīties, ka nav jēgas pildīt testu
B, kamēr nav veiksmīgs tests A
• Tad testam B lieto atribūtu @depends
/**
* @depends testA
*/
public function testB(){
}
30. Datu piegādātāji
• Ir labi veikt testus ar dažādu ievaddatu
kopu
• Nav prātīgi visus ievaddatus "iešūt kodā"
• "Atpārošana" (decoupling) iespējama,
izmantojot @dataProvider atribūtu
• Piegādātājs = metode, kas atgriež testa
datu masīvu
• Piemēros parasti izmanto array(), praksē
varētu nolasīt no DB.
31. Datu piegādātāji – piemērs
class DataTest extends PHPUnit_Framework_TestCase
{
protected static $myData = array(
array(0, 0, 0),
array(0, 1, 1),
array(1, 0, 1),
array(1, 1, 3)
);
public static function provider()
{
return self::$myData;
}
/**
* @dataProvider provider
*/
public function testAdd($a, $b, $c)
{
$this->assertEquals($c, $a + $b);
}
}
32. Kas traucē vienībtestēšanai?
• Jebkas, kas padara testu specifisku
konkrētajam izpildes brīdim vai izsaukumam:
• Globālie mainīgie
– to uzstādīšana traucē veikt tīru testu
• "Singleton" pieeja
– Ir radniecīgi globālajiem mainīgajiem
• Biznesa darba veikšana konstruktorā
• Atkarība no datiem DB vai failu sistēmā
• Koda konstrukcijas:
– privātie & aizsargātie mainīgie