Правила юнит тестирования

Question

Мой вопрос может показаться глупым для некоторых из вас, но я должен спросить .. Извините ..

Я не совсем понимаю принципы модульного тестирования. Как вы можете тестировать классы ваших бизнес-классов?или слой доступа к данным без изменения вашей базы данных?Я объясняю, у меня есть функциональность, которая обновляет поле в базе данных .. Ничего удивительного. Класс бизнес-уровня создается, а метод BLL.Update () создает некоторые элементы управления и, наконец, создает экземпляр класса DAL, который запускает хранимую процедуру вбаза данных с правильными параметрами.

Работает, но у меня вопрос ...

Чтобы выполнить модульные тесты, которые проверяют класс DALayer, я должен воздействовать на базу данных в тестах!Например, чтобы проверить, правильно ли передано значение 5 в базу данных, я должен сделать это, и поле базы данных будет 5 после теста!

Так что я знаю, что обычно тесты не влияют на систему, поэтому я неЯ не понимаю, как вы можете делать тесты без выполнения методов ..

Tx за ответы и извините за мой плохой английский ..

Answer 1

Я разделю ваш вопрос на несколько подвопросов, потому что на них трудно ответить вместе.

Модульное тестирование x Интеграционное тестирование

Когда вы пишете модульный тест, вытестируем простое устройство.Это означает, что вы тестируете один путь выполнения в тестируемом методе.Вы должны избегать тестирования его зависимостей, таких как упомянутая база данных.Обычно вы пишете простой модульный тест для каждого пути выполнения, чтобы обеспечить хорошее покрытие кода вашими тестами.

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

Тестирование бизнес-классов - модульное тестирование

Вам необходимо протестироватьВаши бизнес-классы без зависимости от DAL и DB.Для этого вы должны спроектировать свой класс BL таким образом, чтобы эти зависимости вводились извне.Сначала вам нужно определить абстрактный класс или интерфейс для DAL и передать этот интерфейс DAL в качестве параметра конструктору (другой способ - открыть свойство setable в классе BL).При тестировании класса BL вы будете использовать другую реализацию интерфейса DAL, которая не зависит от БД.Есть хорошо известные тестовые шаблоны Mock, Stub и Fake, которые определяют, как создавать и использовать эти фиктивные реализации.Mocking также поддерживается многими средами тестирования.

Тестирование уровня доступа к данным - интеграционное тестирование

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

С уважением, Ладислав

Answer 2

Для сценария, который вы описываете с точки зрения взаимодействия с БД, насмешка полезна.Если у вас есть шанс, взгляните на Rhino Mocks

Answer 3

Если вы не прибегаете к мошенничеству и не используете реальную БД в тестировании, то это будет интеграционное тестирование с точки зрения непрофессионала и больше не является модульным тестом. Я работал над проектом, в котором выделенный файл sql .mdf находился в системе управления версиями, которая была подключена к серверу базы данных с помощью NUnit в [Setup] части [SetupFixture], аналогично отделенной в [TearDown]. Это делалось каждый раз, когда выполнялся тест NUnit, и может занять очень много времени, в зависимости от того, какой код SQL у вас есть, а также от размера данных, которые могут ухудшиться.

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

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

Answer 4

Вы используете Inversion of Control вместе с насмешливой структурой, например, Rhino Mocks, как кто-то уже упоминал