Основные положения тестирования

[@Fragster]

а я все равно так и не понимаю, как тестировать приложения с БД

[@kmike]

Создавать тестовую БД с какими-то нужными данными и выполнять на ней тесты, потом БД «убивать». Обычно, чтобы это все автоматизировать, используется какой-нибудь фреймворк для тестирования.

[@sst239]

Любая программа имеет данные и состояние. БД всего лишь способ хранения данных и/или состояния.
Признаться, не совсем понимаю вопроса. Чем тестирование программы, использующей БД, принципиально отличается от тестирования программы работающей с файлами или вебсервисами?

[@NikoM]

В модульном тестировании нужно добиться слабой связанности модулей. Этого можно добиться к примеру вынеся интерфейс доступа к БД в виде параметра. При тестировании приложения интерфейс БД будет подменяется mosk-объектами.

[@zloddey]

Моск в тестировании — безусловно, вещь необходимая, а вот для объектов используется термин mock

[@kicum]

Можно писать 2 типа тестов в таком случае.
Первый — модульные. Тестируем один класс и в качестве объекта для работы с БД подсовываем какую-то простую реализацию, которая допустим считает сколько запросов insert мы отправили. Делаем тест(опишу словами, не хочу привязываться к языку программирования).

1. Выставляем счетчик записи на 0
2. создаем тестовые данные для создания записи
3. производим запись
4. проверяем что счетчик теперь 1

По желанию — проверка что именно те данные отправились.
Второй — интеграционные. Работаем с живой тестовой базой.

1. создаем соединение с тестовой базой
2. создаем тестовые данные для создания записи
3. производим запись
4. проверяем что количество записей изменилось

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

[@Stamm]

Для yii можно использовать fixtures — удобная штука.
Наверняка, подобное есть и для других фреймворков.

[@kicum]

Есть во многих фреймворках. Проблема в том что люди зачастую не понимают как это использовать.
Не сработал еще «переключатель» у человека как именно это делать.

[@Stamm]

Ничего, щёлкнет. Я недавно только про такую возможность узнал. После этого даже стал использовать unit тестирование, очень удобно.

[@kicum]

Ну вот, у вас щелкнуло! Поздравляю!) После может поменяться и сама концепция на написание кода, допустим сначала писать тесты, а потом код.

[@Stamm]

Я так принципе и делаю

[@Krofes]

Отлично.
Очень часто не хватает такого текста, что бы «по полочкам». Вещи на интуитивном уровне понятные, но вот такая формализованность и упорядоченность, иногда, очень помогает в повседневной деятельности.

[@vip_delete]

Эта формализованность и упорядоченность общепринятая или это мнение автора?

[@barancev]

Это мнение автора, то есть моё :)

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

Конечно же моё мнение во многом совпадает со мнением других, уважаемых мною авторов, написавших те или иные книги и статьи о тестировании. Да-да, я не всё это сам придумал :) А местами, возможно, с чем-то не совпадает, но они и сами между собой не всегда во всём согласны.

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

[@kspshnik]

"— 403: Access Denied —"

И так на всех картинках :(