Использование PHPUnitTest при отладкке запросов к базам данных

[DVLev]

Использование PHPUnitTest при отладкке запросов к базам данных

Использую PEAR:HPUnitTest для написания тестов PHP кода, но столкнулся с идеологическим вопросом.

Допустим у меня таблица
id, name (id - auto_increment)

Операции над таблицей: add/update/delete/select

Как правильно написать тесты, проверяющие эти функции, само собой интересует не сам код, а именно теория.

Сейчас так:
1. запрашиваем кол-во записей
2. добавляем запись с заранее известным значением
3. получаем LastInsertID
4. проверяем кол-во записей в таблице (чтобы убедиться что запись добавилась, должно быть на 1 больше чем на первом этапе)
5. вытаскиваем данные по id, полученному на 3 этапе
6. проверяем на соответствие
7. делаем update
8. вытаскиваем по id и проверяем на соответствие
9. удаляем
10. запрашиваем кол-во записей, должно быть на 1 меньше

Кто-то может покритиковать, поделиться опытом?

А если идет каскадное обновление с 5 таблицами? Например: добавили запись в одну таблицу, обновили в другой, удалили из третьей. Получается надо писать гигантский тест на проверку всей транзакции, а еще геморойнее его переписывать в случае изменения.

Т.е. по сути вопрос - что должен проверять тест? Может вообще отказаться от теста такого рода операций.?

 

[mrjazz]

Re: Использование PHPUnitTest при отладкке запросов к базам данных

Автор оригинала: DVLev

Т.е. по сути вопрос - что должен проверять тест? Может вообще отказаться от теста такого рода операций.?

Мое субъективное мнение - в такого рода вещах предпочтительнее функциональное тестирование. Т.к. цепь успешных операций на сервере выдает конкретный результат. Задавая исходные данные и проверяя результат вы выполняетет тестирование не привязываясь к конкретной реализации.

 

[syfisher]

Согласен, что в большинстве случаев функционального тестирования достаточно. Модульными тестами нужно покрывать только те операции, который в себя включают специфическую логику (обычно при реализации ActiveRecord). Но по возможности логику выносят из класса, которых работает с базой данных. Получается, что тестировать нужно только DBAL классы и самые верние классы в иерархии. Не забывайте, что модульные тесты - это больше design activity, а не check activity. Тестировать все досконально модульными тестами не всегда рационально.

А так все правильно описал. Мы обычно именно такой последовательности и придерживаемся.

 

[pachanga]

Вот если бы автор пояснил бы, чего именно он пытается добиться, а не просто приводил бы описание на самом низком уровне, то можно было бы посоветовать что-то более конкретное.

Пока же на самом деле все это похоже на реализацию ActiveRecord, TableGateway или нечто похожего. Если это так, то базовый функционал надо тестировать очень тщательно. А тесты для частных случаев просто можно опустить(именно по работе с одной табличкой), ведь в конечном итоге тесты опираются на индукцию.

 

[DVLev]

На самом деле вопрос был из серии "себя показать, других посмотреть".

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

Вышел на Фаулера, почитал, поразмыслил... прочитал 13-ый и 14-ый PHPInside ... понял, что главная проблема в том, что я пытался модульными тестами тестить то, что надо тестировать с помощью SimpleTest или других "функциональщиков".

ОГРОМНОЕ спасибо за то, что натолкнули на размышления и в конечном счете вывели на правильное решение.

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

Еще раз спасибо откликнувшимся.