В настоящее время мы пишем тестовые случаи в нашем проекте. Реализации для методов базы данных существуют и работают нормально. В этом случае зачем нам писать фиктивные объекты? Есть ли какая-то конкретная причина? Почему я не могу проверить реализацию DAO напрямую?
Ответы:
Вы не должны издеваться над вызовами в базу данных, потому что это побьет цель. Например, вы ДОЛЖНЫ высмеивать вызовы вашего DAO, скажем, из уровня обслуживания. Пересмешка позволяет тестировать методы изолированно.
Допустим, у вас есть симулятор ресторана с такой архитектурой:
Cook <=> Server <=> Customer
Вы хотите проверить каждый слой независимо. Здесь Serverваш уровень обслуживания и Cookможет рассматриваться как DAO. Это Serverто, что вы хотите высмеять во время тестирования Customer, и Cookэто то, что вы хотите высмеять во время тестирования Server. Тем не Cookменее, модульные тесты должны подтвердить, что реализация возвращает гамбургер, когда заказан гамбургер, а не резиновая шина.
Это вполне нормально для тестирования businesslogic вместе с базой данных. но эти тесты называются интеграционными тестами, даже если вы используете nunit, junit или phpunit для их выполнения.
Юнит- тесты - это специализированные тесты, в которых важно тестирование изолированно (т. Е. Бизнес- логика без базы данных). Моксы / подделки / вставки используются для обеспечения этой изоляции.
Просто: для проверки фактического DAO, а не содержимого базы данных.
Предположим, у вашего класса DAO Person есть метод getByName (). Вы пишете тест и вызываете Person.getByName («Джон Смит»). Предположим, что тест не пройден, потому что кто-то удалил запись Джона из базы данных. Теперь каждое программное обеспечение CI и ваши супервизоры / рецензенты могут утверждать, что ваше программное обеспечение неисправно, хотя на самом деле это не так. Если вы имитируете БД, вы можете доказать, что ваш DAO работает, если ему дана правильная строка из правильной таблицы.
Если вы действительно хотите проверить саму базу данных, то есть: если выполнение определенного метода DAO переводит данные в определенное состояние, то это также возможно. Более того, это действительно полезно для дурацких моделей данных (EAV, набор вложенных деревьев), где вы не можете ожидать, что база данных обеспечит пуленепробиваемую целостность. Взгляните на DBUnit, чтобы сделать вашу жизнь проще.
Другая причина заключается в том, чтобы избежать времени выполнения команд базы данных. Может показаться, что это немного, но накладные расходы на настройку и разрыв соединений будут со временем увеличиваться и, скорее всего, значительно увеличат общее время запуска набора тестов по сравнению с использованием фиктивных объектов.
Чтобы изолировать класс, который вы тестируете. Или, если тест не пройден, откуда вы знаете, что проблема в классе, который вы тестируете, или в одной из его зависимостей.