Избегайте зависимости базы данных для модульного тестирования без насмешек

Question

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

Мы научимся использовать фиктивные объекты, если нам это нужно, но это кажется чрезмерной нагрузкой, поэтому я ищу альтернативы.

    public class Person
    {
        public string Name;

        public string Validate()
        {
            if (PersonDA.NameExists(Name))
            {
                return "Name Already Used";
            }

        }
    }

Answer 1

Лично я бы просто пошел по маршруту с фиктивным объектом. Это гораздо более гибко и звучит так, будто вы хотите пойти по пути вставки тестового кода в ваш реальный объект?

Независимо от этого извлеките код проверки в объект PersonValidator с помощью метода для логического значения isValid (Person). Затем в тестовом коде используйте фиктивный валидатор, который просто возвращает true или false в зависимости от тестового примера.

Answer 2

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

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

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

Answer 3

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

Answer 4

Почему вы пытаетесь точно избежать насмешек? Если вы собираетесь практиковать модульное тестирование и у вас есть код доступа к данным, вам будет проще освоить способ mock / stub / inject.

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

Размещение кода доступа к данным за интерфейсом позволит избежать необходимости в базе данных. Подумайте об использовании внедрения зависимостей для вставки фиктивного или заглушенного кода доступа к данным во время ваших тестов.

Answer 5

Вы должны просто настроить базу данных, которая используется для модульного тестирования. Если вы используете макеты для всего доступа к данным, вы не будете много тестировать? :)