Автоматизоване тестування з використанням Zend Framework

Мітки: веб-розробка, модульне тестування, zend framework

Автоматизированное тестирование с использованием Zend Framework Автоматизированное тестирование с использованием Zend Framework
Automated Testing Using Zend Framework Automated Testing Using Zend Framework

← Інтеграція FCKeditor в Zend_FormПаттерн кешування для моделей →
Автоматизоване тестування вашого веб-додатку є важливим кроком для впевненості в якості і відсутності погіршення, при внесенні змін у вашу програму. З фреймворком для тестів від Zend Framework (побудований з PHPUnit) ви можете скласти блоки тестових випадків для вашого веб-додатку без найменших зауважень.
У цій статті надана вся базова інформація, яка знадобиться вам при написанні автоматизованих тестів для додатків Zend Framework.

А тепер, давайте перейдемо до справи
У представленому прикладі я буду використовувати дійсний контролер одного з моїх проектів. Цей контролер керує діями, пов'язаними з обліковими записами, такими як вхід, вихід, реєстрація та підтвердження. Ми будемо використовувати тестову базу даних зі схемою, яка клонує нашу базу даних продукції, з Doctrine для управління ORM (вибач, Zend_Db:( ) Я припускаю, що ви використовуєте вищевказану схему проектів Zend Framework (1.6+), і що ви знайомі з Zend_Config і використовуєте плагін контролера Initializer (створений за замовчуванням, якщо ви використовуєте Zend Studio for Eclipse 6.1).

Підготовка вашого додатку
Першим кроком для створення автоматизованого тестування є правильна підготовка оточення і налаштувань вашого додатки. В залежності від ваших установок, це може включати встановлення глобальних змінних, зміна зв'язків бази даних, або перенастроювання шляхів. На щастя для нас, це легко робиться за допомогою у Zend_Config і плагина контролера Initializer.
Zend_Config дозволяє призначати «розділи», які можуть наслідувати з іншого розділу. Це дозволяє змінювати конфігурацію для різних умов без дублювання установок в різних файлах (і таким чином допомагає нам переконатися, що ми нічого не забули!). У нашому тестовому проект нам знадобиться змінити тільки рядок з'єднання з базою даних, значить, ми використовуємо тестову базу даних.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?xml version="1.0" encoding="UTF-8"?>
<config>
 
<production>
  <db>
    <dsn>mysql://dbowner:password@localhost/maindb</dsn>
    <attributes>
        <model_loading>conservative</model_loading>
    </attributes>
  </db>
</production>
<test extends="production">
  <db>
    <dsn>mysql://dbowner:password@localhost/maindb_test</dsn>
  </db>
</test>
</config>

Зверніть увагу, як ми можемо наслідувати дочірні атрибути: хоча ми призначили вузол, нам не потрібно було призначати все, що нижче нього.
Зараз, коли всі наші установки в порядку, нам необходимо что-то для управління ними, а також вимкнення, заснованого на середовищі, в якому ми працюємо. Це роль нашого плагина Initializer, який приймає середовище для ініціалізації як параметр конструктора.

Простий приклад
Давайте почнемо з простого фреймворку тестування контролера. Якщо ви використовуєте Zend Studio для Eclipse, ви можете легко створити цю структуру клацанням правої кнопки на контролері в PHP Explorer, перейти в New>Zend Framework Item і потім вибрати Zend Controller Test Case. Потім просто переконайтеся, що контролер, який ви хочете протестувати, обраний, і натисніть finish.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

<?php
require_once 'Zend/Test/PHPUnit/ControllerTestCase.php';
require_once 'application/Initializer.php';
require_once 'application/default/controllers/IndexController.php';
 
class AccountControllerTest extends Zend_Test_PHPUnit_ControllerTestCase {
 
    /**
     * Підготовка середовища перед запуском тесту
     */
    protected function setUp() {
        $this->bootstrap = array ($this, 'appBootstrap' );
        parent::setUp ();
        // TODO Auto-generated FooControllerTest::setUp()
    }
 
    /**
     * Підготовка середовища перед запуском тесту
     */
    public function appBootstrap() {
        $this->frontController->registerPlugin ( new Initializer( 'test' ) );
    }
 
    /**
     * Очищення середовища після запуску тесту
     */
    protected function tearDown() {
        // TODO Автогенерація FooControllerTest::tearDown()
        parent::tearDown ();
    }
 
    /**
     * Створення умов тесту
     */
    public function __construct() {
        // TODO Автогенерація конструктора
    }
 
    /**
     * Тесты FooController->barAction()
     */
    public function testIndexAction() {
        // TODO Автосгенерірованний
                      // FooControllerTest->testBarAction()
        $this->dispatch ( '/index/index' );
        $this->assertController ( 'index' );
        $this->assertAction ( 'index' );
    }
}

Як ви можете бачити, в рядку 21 ми використовуємо наш ініціалізатор для встановлення тестової середовища до запуску тестів. До запуску кожного тесту, PHPUnit буде викликати наш метод setup (), який був запрограмований на запуск нашого методу appBootstrap. Це гарантує нам, що ми використовуємо чистий конфігурацію і середу перед кожним тестом, так само, як якщо б кожен тест був окремим процесом. Коли всі тести пройдені, викликається метод tearDown (). Це місце для будь-якого коду, який видаляє ресурси або скидає будь-які зміни, які могли зробити тести. Нам знадобиться це пізніше в наших просунутих прикладах.
Рядок 45 містить скелет тестового умови, що буде забезпечувати, що диспетчеризація результатів '/ index / index' в контролері названому 'index' і дії під назвою 'index', були запущені останніми. Це може здаватися тривіальним, але це допоможе виявити помилки пов'язані з вашими контролерами. Якщо буде виявлено непередбачені виняток, затвердження контролера буде помилковим, оскільки він буде запущений останнім.

Запуск ваших тестів
Щоб стаття була сфокусована, я вирішив видалити цей розділ і розповісти лише про написання тестів. Якщо вам потрібна допомога у створенні блоків Тест та запуску тестів з командного рядка, дивіться документацію PHPUnit, особливо розділ про запуск тестів з командного рядка та організації блоків тесту.

Розширення функціональності тестування
Зараз, коли ми розглянули основи, давайте перейдемо до тестування наших контролерів облікових записів. Є пара додаткових вимог для тестування контролера облікових записів. По-перше, нам потрібно протестувати весь процес створення облікового запису так, начебто користувач дійсно реєструється. Коли ми закінчили тестування, необхідно позбутися від усіх можливих даних так, щоб ми могли запускати тест стільки разів, скільки буде потрібно, і не турбувалися про збільшення бази даних. По-друге, нам потрібно спосіб симулювати дії цього користувача, рівним рахунком, як і перевіряти справжній він.
Оскільки ці операції досить загальні, і є можливість їх повторного використання, давайте розмістимо їх в окремий клас і дозволимо тестовим умов їх успадкувати.

Одноразові моделі тестування
Є два способи переконатися в тому, що дані, які створюються протягом тесту, видаляються після його виконання. Деякі воліють створювати бази даних на льоту, використовуючи початкові дані.
Оскільки я використовую Doctrine для моїх проектів і працюю безпосередньо з моделлю (без грубих запитів) в тестах, я вирішив, що просто видалення даних буде кращим рішенням. Для здійснення цього, все що нам необхідно це «призначити» нашу модель для видалення, після того як вона була створена (або завантажена).
Прибрати підсвітку коду
1
2
3
4
5

<?php
protected function _setDisposable( Doctrine_Record $model )
{
    $this->_disposables[] = $model;
}

Ця функція просто дає посилання на модель, і зберігає її в масиві, який пізніше буде керуватися нашої функцією tearDown():
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12

<?php
    protected function tearDown()
     {
        parent::tearDown();
 
        foreach ( $this->_disposables as $model ) {
            if ( $model instanceof Doctrine_Record ) {
                $model->delete();
            }
            unset( $model );
        }
    }

Ми просто проганяє через всі наші «призначені» моделі і вилучаємо їх. Це має бути зроблено в tearDown() і не усередині будь-якого з методів тесту, так як це єдиний спосіб бути впевненим, що воно станеться. Коли затвердження помилково або трапляється несподіване виняток у тесті, цей метод припиняє виконуватися. Якщо ми намагаємося помістити наші моделі після затвердження (assert), це може ніколи не відбутися.
Таким же чином, ми явно не можемо мати моделлю до ассерта, якщо ця модель необхідна для ассерта (і навіщо вона могла б існувати, якщо в ній немає необхідності?).

Підтримка аутентифікації
Всього 3 речі, які ми повинні мати можливість зробити по черзі для повного тесту автентифікації.
• Створити фальшивий ідентифікатор
• Встановити нашу середу в стан еквівалентне користувачеві, який здійснив вхід в систему
• Незалежно від зміни стану середовища, затвердити стан виробленого входу
Наш приклад контролера використовує адаптер бази даних для аутентифікації і пошук ідентифікатора, значить, генерація фальшивого идентификатора означає для нас створення (або завантаження) записи в нашу таблицю облікових записів, і повернення идентификатора даних, який ми зазвичай отримуємо.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<?php
/**
 * Генерація фальшивого ідентифікатора, використовується для симуляції входу користувача в систему
 * @return StdClass an identity
 */
protected function _generateFakeIdentity()
{
    $identity = new stdClass();
 
        $account = new Account();
        $account->username     = 'AutoTest' . time();
        $account->emailAddress = 'autotest@example.org';
        $account->password     = md5( 'password' );
        $account->confirmed    = true;
        $account->enabled      = true;
        $account->save();
        $this->_setDisposable( $account );
 
    foreach( $account->toArray() as $key => $val ) {
            $identity->$key = $val;
    }
    unset( $identity->password );
 
    return $identity;
}

Обліковий запис це наша модель, тип Doctrine_Record. Ми просто створюємо випадкову обліковий запис і повертаємо ці дані як наш ідентифікатор. Зверніть увагу, що ми також встановили цю модель для видалення (як показано вище). Зараз нам необхідно знайти спосіб встановити нашу середу в стан «залогінен», так як це фальшивий користувач.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12

<?php
/**
 * @ Param object $identity - використовується identity, інакше воно буде сгенерировано
  * @return void
 */
protected  function _doLogin( $identity = null )
{
    if ( $identity === null ) {
        $identity = $this->_generateFakeIdentity();
    }
    Zend_Auth::getInstance()->getStorage()->write( $identity );
}

У нашому прикладі програми, якщо Zend_Auth має ідентифікатор, отже, користувач здійснив вхід в систему. Отже, все, що нам потрібно зробити, це зберігати ідентифікатор у сховищі адаптера Zend_Auth, і вважатися увійшли в систему. Це робить ассерт входу настільки ж простим, як і перевірку на ідентифікатор.
 Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10

<?php
public function assertNotLoggedIn()
{
    $this->assertFalse( Zend_Auth::getInstance()->hasIdentity(), 'Login assertion failed' );
}
 
public function assertLoggedIn()
{
    $this->assertTrue( Zend_Auth::getInstance()->hasIdentity(), 'Login assertion failed' );
}

Цей простий ассерт дає впевненість, що ми зробили (або не зробили) вхід в систему.

Складаємо всі разом
Складаючи все це разом, ми тепер маємо базовий клас, який забезпечує всі наші випадки тесту з функціональністю, яка нам необхідна.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

<?php
require_once 'Zend/Test/PHPUnit/ControllerTestCase.php';
 
class BaseControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
 
    /**
     * Включає модель, яка повинна знищуватися в подальшому
     *
     * @var array
     */
    protected $_disposables = array();
 
 
    protected function tearDown()
    {
        parent::tearDown();
 
        foreach ( $this->_disposables as $model ) {
            if ( $model instanceof Doctrine_Record ) {
                $model->delete();
            }
            unset( $model );
        }
    }
 
    /**
 * Встановлює модель як одноразову, таким чином, teardown видалить її автоматично 
     *
     * @param Doctrine_record $model
     */
    protected function _setDisposable( Doctrine_record $model )
    {
        $this->_disposables[] = $model;
    }
 
    /** 
Встановлення поточного стану як користувач, який здійснив вхід 
  * @ Param object $ identity - використовується identity, інакше воно буде сгенерировано
* @return void
     */
    protected function _doLogin( $identity = null )
    {
        if ( $identity === null ) {
            $identity = $this->_generateFakeIdentity();
        }
 
        Zend_Auth::getInstance()->getStorage()->write( $identity );
    }
 
    /**
*Генерація фальшивого ідентифікатора, використовується для симуляції входу користувача в систему
     * @param boolean $unique
     * @return StdClass an identity
     */
    protected function _generateFakeIdentity( $unique = false )
    {
        $identity = new stdClass();
 
        $account = new Account();
            $account->username     = 'AutoTest' . time();
            $account->emailAddress = 'autotest' . time() . '@example.org';
            $account->password     = md5( 'password' );
            $account->confirmed    = true;
            $account->enabled      = true;
            $account->save();
            $this->_setDisposable( $account );
 
            foreach( $account->toArray() as $key => $val ) {
                $identity->$key = $val;
            }
            unset( $identity->password );
 
            return $identity;
    }
 
    public function assertNotLoggedIn()
    {
        $this->assertFalse( Zend_Auth::getInstance()->hasIdentity(), 'Login assertion failed' );
    }
 
    public function assertLoggedIn()
    {
        $this->assertTrue( Zend_Auth::getInstance()->hasIdentity(), 'Login assertion failed' );
    }
 
}

Написання тесту контролера
Тепер, коли наш фундамент закладено, ми можемо, нарешті, почати писати тест контролера.
Наша перша установка випадку тесту буде покривати наступне вимогу: «коли користувачі реєструються, вони повинні підтверджувати свої e-mail адреси до того, як вони отримають доступ до свого облікового запису». Для цього нам необхідно симулювати як користувач відправляє свої коректні реєстраційні дані в наш контролер, і перевіряти, щоб створити обліковий запис не була підтверджена. Потім ми повинні протестувати, що відправляється логін для непідтвердженою облікового запису, який не призведе до авторизації користувача.
Прибрати підсвітку коду
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<?php
public function testRegisterCreatesNewUnconfirmedAccount()
{
    $email = 'autotest' . time() . '@example.org';
    $data = array(
        'emailAddress'    => $email,
        'password'          => 'testpassw0rd',
        'passwordconfirm' => 'testpassw0rd'
    );
 
    $_POST = $data;
 
    $this->dispatch( '/account/register' );
    //намагаємося знайти обліковий запис
    $table = Doctrine_Table::create( 'Account' ) ;
    $account = $table->findOneByEmailAddress( $email );
    $this->_setDisposable( $account );
    $this->assertNotNull( $account );
    $this->assertFalse( $account->confirmed, 'Обліковий запис не була позначена як непідтвердженими' );
}
 
/**
 *  Стверджує, що користувач, який не був підтверджений, не може здійснити вхід в систему
 */
public function testUnconfirmedUserCannotLogin()
{
    $email = 'autotest' . time() . '@example.org';
 
    $account = new Account();
    $account->username     = $email;
    $account->password     = md5( 'password' );
    $account->emailAddress = $email;
    $account->confirmed    = false;
    $account->enabled      = true;
    $account->save();
 
    $this->_setDisposable( $account );
 
    $_POST['username'] = $email;
    $_POST['password'] = 'password';
  
    $this->dispatch( '/account/login' );
    $this->assertFalse( Zend_Auth::getInstance()->hasIdentity() );
    $this->assertNotRedirect();
}


Наш перший тест просто використовує глобальну змінну $_POST для симуляції відправки нашої реєстраційної форми з деякими тестовими даними. Після dispatch(), ми використовуємо Doctrine_Table для пошуку моделі створеної AccountController::registerAction(), потім стверджуємо, що запис була знайдена і що вона не була позначена як підтверджена.
Другий тест працює ручної вставкою записів, які не підтверджені і дають впевненість, що користувачі не пройдуть авторизацію, коли намагаються зробити вхід з даною інформацією по профілю. Як додатковий бонус, ми також використовуємо assertNotRedirect() щоб переконатися, що наш контролер не робить перенаправлення. Наш контролер повинен робити перенаправлення тільки у випадку успішного входу, в інших випадках це вводило б користувача в оману.

Оригінал: Automated Testing Using Zend Framework

Рейтинг: 12345   << Ви можете поставити оцінку цій статті


Подібні статті:
   6 інструментів для того щоб бути ефективним Web-розробником
   Розуміння області видимості в об’єктно-орієнтованому JavaScript
   Введення в мистецтво модульного тестування в PHP
   Інтеграція FCKeditor в Zend_Form
   Паттерн кешування для моделей


Обговорення статті:

 
мирослав [2009-05-26]
Стаття хороша і потрібна. Але не завадило б її на помилки перевірити.

"клонірует", "Підготовка вашого додатки", "почнемо з простого фреймворки" і так далі.


HeeL [2009-05-26]
Дякую, виправлено ;)


 

Залишити коментар:

Ім'я


E-mail


Повідомлення