Разработка через тестирование
Опубликовано: 11 октября 2007

В таких языках программирования, как Java или С++, часть тестирования кода берет на себя компилятор, проверяя, определены ли все переменные, и следя за типами дынных. В языке программирования РНР, который, несомненно можно считать самым популярным средством разработки web-приложений, компилятор к коду относится весьма лояльно. Так, например, любую переменную можно определить где угодно и когда угодно. Нет необходимости явно указывать тип переменной, компилятор все сделает сам. Это нельзя считать ни плюсом, ни минусом, однако из-за этого некоторые разработчики допускают множество ошибок.

Для РНР, как и для другого языка программирования, может быть применен метод разработки через тестирование (TDD) – Test Driven Development. Тестирование – неотъемлемая часть написания ПО, которая помогает обнаружить ошибки и уязвимости в самом начале разработки. Ведь программист не всегда в состоянии предусмотреть все варианты типов входных данных и дальнейшей работы с ними.

Тестирование кода коренным образом меняет отношение к разработке. Для того чтобы привыкнуть тестировать свои приложения, может уйти от нескольких месяцев до года. Тестирования бывает модульным – в таком случае тестируется исходный код программы, а бывает приемочным – тестируется интерфейс программы или попросту соответствие приложения требованиям заказчика. Хорошо разработанные тесты могут вполне заметить документацию к скриптам, и другим программистам, которые впоследствии могут работать с вашим кодом, это намного облегчит понимание и доработку программы. Конечно, для этого тесты должны быть небольшими и понятными.
Иногда тесты даже могут заменить техническое задание: вы пишите тестовый код и потом по нему разрабатывается реализация. Если тесты срабатывают, задание можно считать выполненным.

В качестве средства модульного тестирования приложений, написанных на РНР, мы используем средство автоматического тестирования Simple Test (существуют и другие, но Simple Test весьма прост в освоении и распространяется как Open Source). Скачать последнюю версию Simple Test, а также ознакомиться с тем, как установить этот пакет тестов, можно на сайте: http://simpletest.sf.net . В работе мы используем даже два средства - Simple Test и WACT.

Важным моментом в процессе внедрения тестирования является рефакторинг – улучшение существующего когда без изменения его функциональности.

Впервые применять тестирование мы начали при доработке сайта «Финансы ТУТ» - раздела портала TUT.BY, на котором предоставлена актуальная информация о курсах валют, кредитах, вкладах и банках. Поэтому правильная работа с информацией и точные числовые расчеты здесь очень важны.

Конечно, начинать работу с тестами лучше всего с нового проекта, но этот ресурс подвергся серьезному рефакторингу, и применение метода разработки через тестирование оказалось кстати. При его первоначальной разработке в 2004 году не учитывалась возможность функционального или даже визуального изменения ресурса, поэтому коды некоторых скриптов напоминали «спагетти с соусом», где код на РНР был вперемежку с HTML-кодом, и выглядело это примерно так:

<form action=banks.html method=get>
<table width="100%" border="0" cellspacing="0" cellpadding="0" class=tbl>
 <tr>
 <th><b>Поиск банка по коду</b></th>
 </tr>
 <tr id=brd_none>
 <td colspan="2">Поиск по коду: <input type="text" id=input size=4 name=codes> <input type="submit" value="Найти" class=btn></form><br></td>

 </tr>
<tr>
 <th><B>Поиск банка по названию и/или городу</b></th>
 </tr>
 <tr id=brd_none>
 <td>
<form action=banks.html method=get><br>
 <select name=city style="width:100%">
<option value="">-выберите город-</option>

<?
if (eregi($c,$city)) {echo("<option value='" . $c . "' SELECTED>" .$c. "</option>\n");}
 else {

 echo("<option value='" . $c . "'>" .$c. "</option>\n");
 }

$sql = "SELECT DISTINCT `c_city` FROM `codes` ORDER BY `c_city`;";
$res = mysql_query($sql, $link);
while($ret = mysql_fetch_array($res, MYSQL_ASSOC)) {
 $c=$ret[c_city];
 if ($c !='Минск') {
 if (eregi($c,$city)) {echo("<option value='" . $c . "' SELECTED>" .$c. "</option>\n");}
 else {

 echo("<option value='" . $c . "'>" .$c. "</option>\n");
 }

}
 //echo("<option value='" . $ret["c_city"] . "'>" . $ret["c_city"] . "</option>\n");
}
?>
</select>

Согласитесь, не очень удобно. Это страница поиска банков, над ней мы и будем работать. Естественно, не все страницы ресурса выполняли выборку данных из БД в формате MySQL, поэтому данные и сама инициализация подключения к БД были также прописаны в каждом файле.

Итак, для начала нам пришлось отказаться от процедурного программирования и перейти на объектное: ведь ООП и тестирование друг без друга невозможны.

Далее описаны несколько простых тестов, которые помогут нам проверить работоспособность скрипта.

Шаг 1. Подготовка.

Чтобы нам было проще тестировать, а в дальнейшем и подвергать наши скрипты рефакторингу, мы выделим часть PHP-кода – например, данные для подключения к MySQL вынесем в отдельный файл config.php. Для начала мы посмотрим, как работает наш поиск, для этого подготовим тестовую среду и напишем первый тест. Все наши файлы будут храниться в корневой директории Web-сервера, а Simple Test мы распакуем в папку /test/.

На этом шаге в корневой директории у нас будет всего три файла: config.php – скрипт, содержащий конфигурационные данные, runner.php –скрип, который будет прогонять все наши тесты, и скрипт, содержащий сами тесты - all_my_test.php.

Config.php
<?
 define('SIMPLE_TEST_DIR','test/');
 require_once(SIMPLE_TEST_DIR.'web_tester.php');
 require_once(SIMPLE_TEST_DIR.'reporter.php');
 require_once(SIMPLE_TEST_DIR.'unit_tester.php');
?>

Runner.php

<?
require_once('config.php');

class MyTest extends GroupTest {
 function MyTest() {
 $this->GroupTest('My test');
 //Подключаем все наши тесты, которые будут выполняться
 $this->addTestFile('all_my_test.php');
 }
}

$test = new MyTest();
if(SimpleReporter::inCli()) {
 exit($test->run(new TextReporter())?0:1);
}
$test->run(new HtmlReporter());
?>

Сейчас мы напишем тест, который проверит, как работает наш поиск:
<?
class TestMyProject extends WebTestCase {
 function test_search() {
 //имитируя работу браузера, заходим на нужную нам страницу
 $this->get('http://finance.tut.by/banks.html');
 }
 
 function test_search_form() {
 $this->_input_data('220');
 $this->_test_result();
 }
 
 function _input_data($codes) {
 //имитируем ввод данных и нажатие на кнопку
 $this->setField('codes',$codes);
 $this->clickSubmitByName('submit');
 }
 
 function _test_result() {
 //ищем индекс банка, чтобы проверить, что поиск работает
 $this->assertWantedPattern('/220101/s');
 }
}
?>

При запуске runner.php мы убедимся, что все тесты сработали (об этом нам сообщит зеленая полоска), после чего можно приступать к написанию более сложных тестов. Кстати, запустить все наши тесты можно также и из командной строки.

Шаг 2. Усложняем наши тесты.

Для дальнейшей работы мы написали класс для реализации поиска. Вот несколько методов, которые мы потом будем тестировать:
<?
class Bank{
 var $codes='';
 var $bank_id='';
 var $street_id='';
 
 function Bank($codes,$bank_id,$street_id) {
 $this->bank_id = $bank_id;
 $this->codes = $codes;
 $this->street_id = $street_id;
 }
 
 function _GetCodes() {
 return $this->codes;
 }
 
 function _GetBankId() {
 return $this->bank_id;
 }
 
 function _GetStreetId() {
 return $this->street_id;
 }
 
 function _GetRequestArray() {
 $query="SELECT * FROM tbl_banks WHERE codes='{$this->codes}' OR bank_is='{$this->bank_id}' OR street_id='{$this->street_id}'";
 $result=mysql_query($query);
 $row = mysql_fetch_array($result);
 return $row;
 }
}

?>

Тут есть не только конструктор, но и так называемые геттеры – методы, возвращающие необходимые данные.
Нам важно, чтобы все данные, входящие в наш класс, были нужного нам типа и вообще присутствовали. Напишем небольшой тест для этого. Файл all_my_test.php будет выглядеть следующим образом:

<?
require_once('bank.class.php');

class TestMyProject extends UnitTestCase {
 function TestCodes() {
 $bank = new Bank('1','2','3');
 $this->assertTrue($bank->_GetCodes());
 $this->assertNotA($bank->_GetCodes(),'int');
 }
 
}
?>

Тут все очень просто: вначале проверяем на наличие нашей переменной codes
$this->assertTrue($bank->_GetCodes());
– а затем на соответствие переменной нужному нам типу.
$this->assertNotA($bank->_GetCodes(),'int');

Точно таким же образом можно проверить и на работоспособность функции, выполняющие SQL запрос:

<?
require_once('bank.class.php');

class TestMyProject extends UnitTestCase {
 function TestCodes() {
 $string = (int)0;
 $bank = new Bank('1','1','1');
 $this->assertTrue($bank->_GetCodes());
 $this->assertNotA($bank->_GetCodes(),$string);
 }
 
 function TestRequest() {
 $bank = new Bank('1','2','3');
 $this->assertTrue($bank->_GetRequestArray());
 }
 
}
?>

Кроме проверки на простейшее соответствие текущая версия Simple Test имеет следующие тестовые функции:

assertTrue($x) — выдается ошибка, если значение False;
assertFalse($x) — получаете ошибку тестирования, если переданное значение True;
assertNull($x) — проверка, существует ли переданное значение;
assertNotNull($x) — указанное в параметрах метода значение не должно существовать;
assertIsA($x, $t) — переменная $x не должна иметь тип $t;
assertNotA($x, $t) — проверка на соответствие типа переменной $x строке $t;
assertEqual($x, $y) — проверка на равенство $x и $y;
assertNotEqual($x, $y) — проверка на неравенство $x и $y;
assertWithinMargin($x, $y, $m) — проверка того, что разница $x и $y меньше $m;
assertOutsideMargin($x, $y, $m) — разница $x и $y больше $m;
assertIdentical($x, $y) — проверка полной идентичности (одновременно типа и значения переменных);
assertNotIdentical($x, $y) — проверка неидентичности значений;
assertReference($x, $y) — ошибка выдается, если $y не является ссылкой на переменную $x;
assertCopy($x, $y) — в случае если $y — ссылка на $x, выдается ошибка;
assertPattern($p, $x) — проверка строки $x по регулярному выражению $p;
assertNoPattern($p, $x) — несоответствие строки $x регулярному выражению $p;
assertNoErrors() — при выполнении кода не было ошибок;
assertError($x) — в коде должна быть ошибка.

Кстати, бывает так, что некоторые разработанные методы используют в своей работе другие методы, которых пока нет. Естественно, в этом случае тесты не срабатывают. На помощь в таком случае приходят Мок-объекты. Мок-объекты – это заглушки в коде, которые могут имитировать работу необходимых методов и даже целых классов.
Например, нам нужно имитировать работу класса, выполняющего подключение к базе данных. Это может выглядеть так:

<?
require_once('simpletest/unit_tester.php');
require_once('simpletest/mock_objects.php');
require_once('database_connection.php');

Mock::generate('DatabaseConnection');

class MyTestCase extends UnitTestCase {
 
 function testSomething() {
 $connection = &new MockDatabaseConnection();
 }
}
?>
Таким же образом можно создать методы имитируемого класса и заставить их возвращать необходимые данные. Подробнее о Мок-объектах можно прочитать на сайте http://simpletest.sourceforge.net .

Приведенные выше тесты весьма и весьма просты, однако помогают на начальном этапе проверить работоспособность скрипта и избежать неприятностей в дальнейшем. Конечно, в своей работе мы используем тесты намного сложнее и длиннее описанных в этой статье, а их количество в процессе разработки достигает нескольких сотен.

В этой статье основное внимание было уделено модульному тестированию, или проверке кода программы на «живучесть». Но это лишь одна часть тестирования. Как я уже отмечал, есть еще и приемочное тестирование. Одним из наиболее распространенных пакетов для эмуляции браузера и проверки работоспособности сайта является Selenuim http://www.openqa.org/selenium.
Вся прелесть среды тестирования заключается в том, что оно представляет собой простое объектно-ориентированное JavaScript-приложение, которое не составляет труда настроить под свои нужды. Чтобы начать работать с Selenium, его достаточно распаковать в любую директорию на Web-сервере и запустить через браузер файл TestRunner.html. Примеры тестов, написанных для этого инструмента, есть в стандартной поставке. Более того, с помощью этих тестов Selenium может протестировать даже сам себя!

К сожалению, тестирование еще не так распространено среди РНР-разработчиков настолько, насколько хотелось бы. Причин много: плохое понимание ООП, нежелание работать быстрее и качественнее или просто незнание о существовании пакетов тестирования.

 Для тех, кто всерьез задумывается о переходе на такой метод разработки своего ПО, я бы хотел дать несколько советов:

• Делайте компактные тесты.
Не забывайте о том, что тесты могут служить документацией к вашему коду, поэтому старайтесь делать их как можно более короткими и понятными. Не старайтесь в один тестовый метод «засунуть» проверку всего сразу. Также не забывайте о том, что тесты не должны зависеть от внешних ресурсов.

• Улучшайте Ваши тесты.
Рефакторинг – неотъемлемая часть метода разработки через тестирование. Причем нужно подвергать рефакторингу не только код ваших тестов, но также и тестируемый код.

Таким образом, при применении данных методик качество и скорость разработки увеличивается, а количество ошибок в коде уменьшается. Не это ли, в конце концов, требуется от хорошего программиста?

Сведения об авторе

Виктор Комягин – инженер-программист УП «Надежные программы». Занимается разработкой различных сервисов белорусского портала TUT.BY. С ним можно связаться по e-mail victor@tutby.com.

Виктор Комягин
Все публикации | Октябрь 2007 | Июль 2006 | Апрель 2006 | Март 2006 | Июнь 2005 | Май 2005

Итак, вы решили создать свой сайт. Уже выбрана тема, есть идеи, определены материалы, которые необходимо выкладывать на сайт. Но прежде чем перейти непосредственно к проектированию содержания и оформления сайта, следует посмотреть на еще кое-что.