Макет моей базы данных для всех модульных тестов в PHPUnit

Question

Я только недавно начал изучать модульное тестирование с помощью PHPUnit и задавался вопросом, можно ли макетировать всю мою базу данных для всех моих тестов.Мои классы моделей (объекты Table Row, обернутые, чтобы обеспечить реализацию ActiveRecord) внедряются в базу данных, и некоторые модели имеют много уровней других классов моделей, поэтому насмешка над всем этим, похоже, станет проблемой в задней части.

Можно ли заставить PHPUnit использовать данные из CSV-файла в качестве базы данных и запускать мои тесты с данными, не затрагивая мои DAO?Я читал раздел о тестировании базы данных в PHPUnit, но я не уверен, что это то, что я хочу, потому что я не столько хочу тестировать базу данных или код, взаимодействующий с базой данных, сколько тем, что мои классы моделейочень привязан к базе данных, и было бы больно постоянно дразнить вещи.Если бы я мог предоставить ему файл CSV для использования в качестве базы данных, я мог бы просто поместить свои данные в файл CSV и продолжить в обычном режиме.

Не уверен, что я все проясняю, поэтому, пожалуйста, попросите разъяснений,Если это возможно, это было бы здорово.Без этого модульного тестирования этот зверь может быть не практичным, но я действительно хочу ввести модульное тестирование в проект.

Спасибо

Зиад

Answer 1

На мой взгляд, использование DBUnit для тестирования вашего зависимого от БД кода имеет несколько преимуществ.Это может относиться или не относиться ко всем, я согласен.Я сам не использовал DBUnit до самого недавнего времени, поскольку обнаружил, что для небольших проектов, в которых я участвую, это было излишним.

Использование DBUnit разъединяет ваши тесты с базой данных.Ваша тестируемая система не должна зависеть от того, какой сервер БД будет работать, вам нужна как можно большая изоляция.Обычно это не имеет большого значения, поскольку многие люди используют модульные тесты для интеграционного тестирования, и для этого вы бы предпочли использовать настройку базы данных, максимально соответствующую вашей производственной среде.

Еще одна причина, по которой DBUnit выгоден, заключается в экономии времени при написании тестов.Написание тестов - это не та часть программирования, которая мне нравится делать, и использование имитаций, когда это возможно, экономит много времени.Конечно, создать копию вашей базы данных легко, но вам все равно придется создавать скрипты для загрузки тестовых данных, иметь скрипты для сброса тестовых данных между каждым тестовым прогоном.Многие тесты будут зависеть от конкретных наборов данных, и их будет сложнее поддерживать по мере добавления тестов.Конечно, все эти настройки должны быть синхронизированы с вашим реальным приложением по мере его развития.В зависимости от приложения это может занять очень отнимание времени.В некоторых приложениях есть тысячи тестов, и это печально, когда простое изменение в приложении приводит к необходимости переписать 20 тестов и их наборы данных.

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

Мои 2 цента, добрый день, друг.

Answer 2

Как насчет использования вашей базы данных, но не внесения изменений?Или откатится после запуска тестов?Мы используем копию нашего производственного сайта в качестве тестовой среды на отдельном сервере и проводим там все наши тесты.

Answer 3

Техника, которая работала для меня раньше, - это напрямую смоделировать адаптер базы данных и вставить макет в цепочку зависимостей.Однако это работает только для очень маленьких блоков, поскольку очень сложно заставить фиктивный адаптер возвращать структуру массива, которую вы ожидаете получить от определенного запроса.Если в один вызов метода вовлечено несколько запросов, это вообще не сработает.

Другая тактика, с которой я добился успеха, - это использование dbUnit только для setUp и tearDown базы данных.Данные фикстуры хранятся в файле XML или Yaml и импортируются в пустую базу данных перед каждым тестом, обеспечивая известное состояние.Учитывая схему и минимальный набор данных, база данных в памяти будет выполнять тесты достаточно быстро, избегая проблемы дискового ввода-вывода.

Наконец, подумайте, если вам даже нужно для записитесты на постоянство данных ... Если вы тестируете реализацию ActiveRecord, у вас, вероятно, есть несколько тестов, которые подтверждают основные операции CRUD на уровне библиотеки.То, что вы действительно заинтересованы в тестировании, зависит не от базы данных, а от того, что объекты в памяти ведут себя, как и ожидалось, при заданной известной начальной точке.Вы можете получить известную отправную точку, создав объект в памяти , не загружая его и не сохраняя его вообще в базе данных.

Просто установите ожидаемое состояние в памяти, создав несколько объектов,Прорабатывайте бизнес-логику, опрашивайте конечное состояние и никогда не называйте «сохранить» ... Или как вы там это называли.Если все, что вам нужно, это объект, который выглядит как соединение с базой данных, чтобы удовлетворить зависимость, у вас есть для этого насмешка ...

Answer 4

Возможно, вы могли бы создать копию БД и просто подключиться к этой копии в своих тестовых загрузочных системах?

Я нахожусь в такой же ситуации, и сейчас я работаю над этим вариантом ... Не идеально, но, по крайней мере, первые тесты работают