Насмешка по сравнению с тестом DB?
Параметрированный запрос И проверка ввода - это путь. Существует множество сценариев, в которых может произойти SQL-инъекция, хотя используется mysql_real_escape_string().
Эти примеры уязвимы для SQL-инъекции:
$offset = isset($_GET['o']) ? $_GET['o'] : 0;
$offset = mysql_real_escape_string($offset);
RunQuery("SELECT userid, username FROM sql_injection_test LIMIT $offset, 10");
или
$order = isset($_GET['o']) ? $_GET['o'] : 'userid';
$order = mysql_real_escape_string($order);
RunQuery("SELECT userid, username FROM sql_injection_test ORDER BY `$order`");
В обоих случаях вы не можете использовать ' для защиты инкапсуляции.
Источник : Непредвиденная инъекция SQL (при эвакуации Недостаточно)
7 ответов
Я думаю, что вы, вероятно, захотите провести некоторое интеграционное тестирование, чтобы проверить логику, которая обеспечивается вашей структурой базы данных, например, ограничения, триггеры, столбцы автоинкремента и т. Д. Однако для модульного тестирования вы должны макетировать любые компоненты инфраструктуры. что ваш DAL полагается так, как вы хотите (в своих модульных тестах) тестировать только те компоненты, которые вы кодировали. Вам не нужно тестировать методы на SqlCommand или SqlConnection (например). Вы должны предположить, что используемые вами компоненты инфраструктуры работают и создают для них заглушки или макеты, которые возвращают известные данные (хорошие, плохие, исключения) в ваши методы, чтобы убедиться, что ваши методы работают правильно. Без насмешек вы несете ответственность за создание данных в базе данных и обеспечение их правильности. Вы также оставляете открытыми зависимости от сети, самой базы данных и т. Д., Что может сделать ваши тесты хрупкими.
Кроме того, модульное тестирование не устраняет необходимость в других типах тестирования. Интеграционные тесты и приемочные тесты все еще действительны и должны быть сделаны. Они, вероятно, не должны выполняться с той же частотой, что и модульные тесты, и не обязательно должны быть настолько обширными, насколько качество вашего кода улучшается с помощью модульного тестирования, но модульное тестирование - это не волшебная палочка.
Я не нашел насмешку очень полезной при тестировании кода доступа к данным. Цель поблочного тестирования состоит в том, чтобы проверить связанные с базой данных работы кода, и насмешка базы данных препятствовала бы тесту.
Насмешка действительно становится полезной при тестировании бизнес-кода. Можно дразнить вызовы базы данных, чтобы возвратить данные тестирования и проверить поведение бизнес-логики при тех обстоятельствах.
Относительно использования транзакций - это, конечно, возможно, пока Ваша архитектура имеет пространство для запуска транзакции в начале теста и затем выполнения всех связанных с базой данных вызовов Вашего модульного теста в той транзакции. Никогда не пробовал его, все же.
Помещение юнит-тестов в транзакции, которые откатывают, звучит хакерски. Вместо этого у меня есть код, который очищает базу данных от любого типа (то есть всего, что не является статическими / справочными данными) перед запуском тестов (т.е. в конструкторе моего тестового класса). Когда ваши тесты проваливаются, это помогает хранить данные в базе данных, чтобы проверить причину сбоя.
мы использовали тесты транзакции, и предотвращенный В спящем режиме, отображая проблемы несколько раз. Иначе - что к модульному тесту? Что-то тривиальное как List<Item> getAllItems()?:)
Используя тестовую базу данных, вы открываете возможность возникновения проблем в самой базе данных или на пути связи (сеть и т. Д.) Между DAL и базой данных. Насмешка исключает эти возможности.
Однако вы не просто тестируете свое приложение. Вы также тестируете свою конфигурацию и свои хранимые процедуры и представления. Они задокументированы в ваших модульных тестах
Это не только состояние DB, который необходимо рассмотреть, это - также доступность. Если Ваш DB в режиме офлайн, почему должен весь Ваш тестовый сбой DAL?
то, Что необходимо протестировать, - то, что DAL дает корректные команды для создания / получают / обновление / удаляет. Вы не должны выполнять SQL для этого, можно просто использовать объектную платформу персистентности и проверить, что Вы даете ему корректные инструкции.