Как делают Вас бизнес-приложения модульного теста?
Ключевое слово is - это тест для идентификации объекта, а == - сравнение значений.
Если вы используете is, результат будет истинным тогда и только тогда, когда объект является тот же объект. Однако == будет истинным в любое время, когда значения объекта будут одинаковыми.
6 ответов
У меня есть к второму комментарий @Phil Bennett, поскольку я пытаюсь приблизиться к этим интеграционным тестам с решением для отката.
у меня есть очень подробное сообщение об интеграционном тестировании Ваш уровень доступа к данным здесь
, я показываю не только демонстрационный класс доступа к данным, базовый класс, и демонстрационный класс приспособления транзакции DB, но полный интеграционный тест CRUD w/демонстрационные показанные данные. С этим подходом Вам не нужны несколько тестовых баз данных, поскольку можно управлять данными, входящими с каждым тестом и после того, как тест завершен, транзакции являются всем rolledback, таким образом, DB является чистым.
О бизнес-логике поблочного тестирования в Вашем приложении, я был бы также второй комментарии @Phil и @Mark, потому что при насмешке всех зависимостей бизнес-объект имеет, становится очень просто протестировать прикладную логику один объект за один раз;)
Редактирование: Таким образом, Вы ищете один огромный интеграционный тест, который проверит все от логической предварительной базы данных / хранимая процедура выполненная w/логика и наконец проверка на пути назад? Раз так Вы могли выломать это в 2 шага:
-
1 - Модульный тест логика, которая происходит перед данными, продвинута в Ваш код доступа к данным. Например, если у Вас есть некоторый код, который вычисляет, некоторые числа на основе некоторых свойств - пишут тест, который только проверяет, чтобы видеть, делает ли логика для этой 1 функции то, что Вы попросили, чтобы он сделал. Насмешка любая зависимость от класса доступа к данным, таким образом, можно проигнорировать его для этого теста одной только прикладной логики.
-
2 - Интеграционный тест логика, которая происходит, как только Вы берете свои данные, которыми управляют (из предыдущего метода мы протестированная единица) и называете соответствующую хранимую процедуру. Сделайте эту внутреннюю часть данные определенный класс тестирования, таким образом, можно откатывать после того, как это завершается. После того, как Ваша хранимая процедура работала, сделайте запрос против базы данных для получения объекта теперь, когда мы сделали некоторую логику против данных и проверяем, что это имеет значения, которые Вы ожидали (логика постхранимой процедуры / и т.д.)
при необходимости в записи в базе данных для хранимой процедуры, чтобы выполнить, просто вставить те данные перед выполнением sproc, который имеет логику в нем. Например, если у Вас есть продукт, который необходимо протестировать, он мог бы потребовать, чтобы поставщик и запись категории вставили поэтому, перед вставкой продукта, делают быструю и грязную вставку для поставщика и категории, таким образом, продукт вставляет работы как запланировано.
Мои автоматизированные функциональные испытания обычно следуют за одной из двух скороговорок:
- База данных Связанные Тесты
- Ложные Тесты Слоя Персистентности
База данных Связанные Тесты
, Когда я автоматизировал тесты, которые подключены к базе данных, я обычно заставляю единственную тестовую базу данных обработать по шаблону, который имеет достаточно данных для всех тестов. Когда автоматизированные тесты запущены, новая тестовая база данных сгенерирована из шаблона для каждого теста. Тестовая база данных должна постоянно повторно создаваться, потому что тест будет часто изменять данные. Поскольку тесты добавляются, я обычно добавляю больше данных к тестовому шаблону базы данных.
существуют некоторые хорошие преимущества для этого метода тестирования. Очевидное преимущество состоит в том, что тесты также осуществляют Вашу схему. Другое преимущество состоит в том, что после установки начальных тестов, самые новые тесты будут в состоянии снова использовать существующие данные тестирования. Это облегчает добавлять больше тестов.
оборотная сторона - то, что тестовая база данных станет громоздкой. Поскольку данные будут обычно добавляться один тест во время, это будет непоследовательно и возможно даже нереалистично. Вы также закончите тем, что прокляли человека, кто устанавливает тестовую базу данных, когда существует значительное изменение схемы базы данных (который для меня обычно подразумевает, что я заканчиваю тем, что проклял меня).
Этот стиль тестирования, очевидно, не работает, если Вы не можете генерировать новые тестовые базы данных по желанию.
Ложные Тесты Слоя Персистентности
Для этого шаблона, Вы создаете фиктивные объекты что живой с тестовыми сценариями. Эти фиктивные объекты прерывают вызовы к базе данных так, чтобы можно было программно обеспечить соответствующие результаты. В основном, когда код, который Вы тестируете, звонит findCustomerByName() метод, Ваш фиктивный объект называют вместо слоя персистентности.
хорошая вещь об использовании тестов фиктивного объекта состоит в том, что можно стать очень конкретными. Часто времена, существуют пути выполнения, что Вы просто не можете достигнуть в автоматизированных тестах w/o фиктивных объектов. Они также освобождают Вас от поддержания большого, монолитного набора данных тестирования.
Другое преимущество является отсутствием внешних зависимостей. Поскольку фиктивные объекты моделируют слой персистентности, Ваши тесты больше не зависят от базы данных. Это часто - решающий фактор при выборе который шаблон выбрать. Фиктивные объекты, кажется, получают больше тяги при контакте с системами унаследованной базы данных или базах данных со строгими условиями лицензирования.
оборотная сторона фиктивных объектов - то, что они часто приводят к большому количеству дополнительного тестового кода. Это не ужасно, потому что почти любой объем тестирования кода является дешевым, когда амортизируется по количеству раз, Вы запускаете тест, но это может быть раздражающим для имения большего количества тестового кода тогда производственный код.
Это зависит от того, что Вы тестируете. При тестировании компонента бизнес-логики - тогда ее несущественное, куда данные прибывают из, и Вы, вероятно, использовали бы насмешку или скрученный вручную тупиковый класс, который моделирует стандартную программу доступа к данным, которую компонент назвал бы в дикой природе. Единственное время, которое я смешиваю с доступом к данным, - когда я на самом деле тестирую сами компоненты доступа к данным.
Даже тогда я склонен открывать транзакцию DB в методе TestFixtureSetUp (очевидно, это зависит, на какой платформе поблочного тестирования Вы могли бы использовать) и откатывают транзакцию в конце набора тестов TestFixtureTeardown.
Дразнящие Платформы позволяют Вам протестировать свои бизнес-объекты. Управляемые данными тесты часто заканчивают тем, что стали большим количеством теста intergration, чем модульный тест, они также несут с ними нагрузку управления состоянием хранилища данных пред и отправляют выполнение теста и время, потраченное в соединении и выполнении запросов.
В целом я постарался бы не делать модульные тесты, которые касаются базы данных от Ваших бизнес-объектов. Что касается Тестирования Вашей базы данных Вам нужен различный stratergy.
, Что, будучи сказанным Вы никогда не можете полностью убегать от управляемого данными тестирования, только ограничивающего amout тестов, которые на самом деле должны вызвать Ваши системы бэкэнда.
Это кажется, что Вы могли бы тестировать основанные на сообщении системы или системы с высоко параметризованными интерфейсами, где существуют большие количества перестановок входных данных.
В целом все правила стандарта unti тестирующий все еще содержат:
- Попытка сделать единицы протестированными максимально маленький и дискретный.
- Попытка сделать тесты независимыми.
- Фактор кодируют для разъединения зависимостей.
- насмешки Использования и тупики для замены зависимостей (как dataaccess)
, Как только это сделано, Вы удалите большую сложность от тестов, надо надеяться, показывая хорошие наборы модульных тестов, и упрощая демонстрационные данные.
А хорошая методология для того, чтобы затем скомпилировать демонстрационные данные для теста, которые все еще требуют, сложные входные данные Ортогональное тестирование , или см. здесь .
я использовал такой метод для генерации планов тестирования относительно WCF и решений BizTalk, где перестановки входных сигналов могут создать несколько возможных путей выполнения.
Для большого количества различных выполнений по той же логике, но с различными данными можно использовать CSV, столько столбцов, сколько Вам нравится за вход и последнее для вывода и т.д.