CakeTestSuite i pokrycie kodu (code coverage)

Nareszcie działa ;) Okazuje się, że zmuszenie powyższego do poprawnego działania za pomocą dostępnych oficjalnych opisów nie jest takie proste.

Np. metoda podana pod http://bakery.cakephp.org/articles/view/testing-models-with-cakephp-1-2-test-suite dla testu modelu się nie sprawdza. Okazuje się, że tam jest podany stary model tworzenia testów. Poprawna klasa powinna wyglądać mniej więcej tak:


App::import('model', 'Article');
class ArticleTestCase extends CakeTestCase {
var $fixtures = array( 'app.article' );

function start() {
parent::start();
$this->Article= & ClassRegistry::init('article');
}

function testPublished() {
$result = $this->Article->published(array('id', 'title'));
$expected = array(
array('Article' => array( 'id' => 1, 'title' => 'First Article' )),
array('Article' => array( 'id' => 2, 'title' => 'Second Article' )),
array('Article' => array( 'id' => 3, 'title' => 'Third Article' ))
);
$this->assertEqual($result, $expected);
}
}

zamiast podanej:

loadModel('Article');
class ArticleTest extends Article {
var $name = 'ArticleTest';
var $useDbConfig = 'test_suite';
}
class ArticleTestCase extends CakeTestCase {
var $fixtures = array( 'article_test' );
function testPublished() {
$this->ArticleTest =& new ArticleTest();
$result = $this->ArticleTest->published(array('id', 'title'));
$expected = array(
array('ArticleTest' => array( 'id' => 1, 'title' => 'First Article' )),
array('ArticleTest' => array( 'id' => 2, 'title' => 'Second Article' )),
array('ArticleTest' => array( 'id' => 3, 'title' => 'Third Article' ))
);
$this->assertEqual($result, $expected);
}
}

Drugi przypadek generuje następujące problemy:

  1. Gdy testy masz ustawione tak, żeby korzystały z tej samej bazy, gdzie masz “normalne” tabele, to testy na zmianę będą wykonywać się poprawnie i zgłaszać błąd z nieistniejącą tabelą (`articles_test`)
  2. Gdy masz osobną baze do testów – będą się sypać relacje. Pewnie zdefiniowanie wszystkich fixtures powiązanych z testowanym modelem rozwiązało by problem, ale nie sprawdzałem.

Kolejnym przypadkiem jest zmuszenie CakeTestSuite do wywalenia informacji o procentowym pokryciu kodu testami. Pominę problemy przy instalacji xdebug, założę, że już to masz za sobą.

Prawdopodobnie będziesz dostawał Segmentation Fault po kliknięciu “Analyze Code Coverage”. Jeśli tak, odnajdź poniższą linię w pliku cake/test/lib/code_coverage_manager.php:

xdebug_start_code_coverage(XDEBUG_CC_UNUSED | XDEBUG_CC_DEAD_CODE);

Niestety Xdebug sypie się przy takim wykonaniu xdebug_start_code_coverage. Możesz zmienić tą linię na

xdebug_start_code_coverage(XDEBUG_CC_UNUSED)

lub

xdebug_start_code_coverage(XDEBUG_CC_DEAD_CODE)

O rożnicy możesz poczytać w dokumentacji Xdebug.

Ostatnia sprawa to pokrycie kodu, gdy wykonujesz test całej grupy. Jeśli chcesz dostawać informacje o pokryciu dla poszczególnych testów, nie używaj TestManager::loadTestCasesFromFile, ale raczej ładuj każdy plik osobno za pomocą TestManager::addTestFile.

To na razie tyle. Miłego testowania ;)

W tej branży 2+2 nie równa się 4

Ten problem nakreślił niedawno Patrys na blogu, który czytuję (http://room-303.com/blog/2009/02/20/przypowiesc-o-osobomiesiacu/) Mam ochotę napisać o tym nieco więcej.

Ciągle mam problem ze złym podejściem do produktu jakim jest oprogramowanie. Dlatego będę pisał o tym pewnie za każdym razem, gdy da mi się we znaki. Jak zwykle zpróbuję opisać to na przykładzie.

Załóżmy, że pytasz mnie ile czasu pracy jednego programisty zajmnie gdyby miał zaprogramować:

- Prosty blog
 Ja odpowiem, że dwa miesiące.
- Galerię zdjęć
Ja również odpowiem, że dwa miesiące.

Jeśli uważasz, że to wystarczające szacowania i gdybyś chciał dostać system, który ma funkcjonalności kryjące się pod hasłem “Prosty blog” i “Galeria zdjęć”, oszacujesz już sobie sam, że to razem 4 miesiące…

Otóż jesteś w błędzie. Ten nowy system zajmie więcej czasu.

Jeśli uważasz, że przypisując czterech programistów do tego projektu czas jego wykonania skróci się czterokrotnie – również się pomyliłeś. Zapomniałeś o tym, że nie zawsze można podzielić projekt na kilka niezależnych elementów, które można implementować współbierznie. Nawet gdyby się dało – ktoś musi odwalić tą robotę, odpowiednio zaprojektować i koordynować współbierzną implementację.

Dlatego jeśli jesteś menadżerem, kierownikiem projektu, sponsorem lub klientem – oddasz przysługę wielu ludziom, jeśli przestaniesz traktować tworzenie oprogramowania jak skręcanie długopisów.
Nam zaoszczędzisz nerwów i wrzodów na żałądku, a sobie – rozczarowań.

W tej branży 2+2 nie równa się 4

Ten problem nakreślił niedawno Patrys na blogu, który czytuję (http://room-303.com/blog/2009/02/20/przypowiesc-o-osobomiesiacu/) Mam ochotę napisać o tym nieco więcej.

Ciągle mam problem ze złym podejściem do produktu jakim jest oprogramowanie. Dlatego będę pisał o tym pewnie za każdym razem, gdy da mi się we znaki. Jak zwykle zpróbuję opisać to na przykładzie.

Załóżmy, że pytasz mnie ile czasu pracy jednego programisty zajmnie gdyby miał zaprogramować:

- Prosty blog
 Ja odpowiem, że dwa miesiące.
- Galerię zdjęć
Ja również odpowiem, że dwa miesiące.

Jeśli uważasz, że to wystarczające szacowania i gdybyś chciał dostać system, który ma funkcjonalności kryjące się pod hasłem “Prosty blog” i “Galeria zdjęć”, oszacujesz już sobie sam, że to razem 4 miesiące…

Otóż jesteś w błędzie. Ten nowy system zajmie więcej czasu.

Jeśli uważasz, że przypisując czterech programistów do tego projektu czas jego wykonania skróci się czterokrotnie – również się pomyliłeś. Zapomniałeś o tym, że nie zawsze można podzielić projekt na kilka niezależnych elementów, które można implementować współbierznie. Nawet gdyby się dało – ktoś musi odwalić tą robotę, odpowiednio zaprojektować i koordynować współbierzną implementację.

Dlatego jeśli jesteś menadżerem, kierownikiem projektu, sponsorem lub klientem – oddasz przysługę wielu ludziom, jeśli przestaniesz traktować tworzenie oprogramowania jak skręcanie długopisów.
Nam zaoszczędzisz nerwów i wrzodów na żałądku, a sobie – rozczarowań.