BDD / TDD обманывает данные хитрым способом

Question

Итак, мы с коллегой ведем довольно жаркие споры. Мы начинаем новый проект и пытаемся использовать BDD. Мы оба новички и не до конца понимаем, какие практики следует использовать. Мы написали некоторые спецификации и сейчас реализуем код. Все становится довольно сложно, так как существует много взаимодействий с базой данных. Мы застряли на том, как мы должны издеваться над нашими данными. Метод, о котором мы говорили, требовал, чтобы мы высмеивали наши методы вместо наших данных. Проще всего, если я покажу вам код ...

public static void AssignLeadToDistributor(int leadId, int distributorId)
{
    Lead lead = GetById(leadId);
    lead.DistributorId = distributorId;
    Save(lead);
}

По сути, мы должны были бы переопределить GetById () и Save (), чтобы вернуть фиктивные данные, чтобы мы могли проверить это. Кажется, имеет смысл сделать это так:

public static void AssignLeadToDistributor(Lead lead, Distributor distributor)
{
   lead.DistributorId = distirbutor.Id;
}

Тогда мы могли бы просто высмеять наши объекты.

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

Надеюсь, я объяснил это достаточно хорошо.

Что вы, ребята, думаете? Какой способ имеет больше смысла?

Answer 1

Я думаю, что самая большая проблема, с которой вы столкнулись, заключается в том, что вы используете публичные статические функции (что, как правило, плохо в языках OO).

Я бы предложил перенести эту функцию на объект Lead, что-то вроде

public AssignDistributor(int distributorId) {
   this.DistributorId = distributorId;
   this.Save();
}

Легче тестировать и больше ОО-подобного кода =)

Answer 2

Что мы делаем в наших спецификациях BDD (исполняемые истории), так это вообще не надругаться над БД, а вместо этого использовать БД в памяти (в нашем случае SQLite).

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

Определяя наши спецификации BDD таким образом, мы обнаружили, что необходимость в модульных тестах и ​​интеграционных тестах уменьшилась, а также возросла производительность и понятность (хотя и очень субъективная, поскольку вы не можете реально измерить эти показатели).

Answer 3

Мне больше нравится второй метод, по той причине, что вы заявили: вы можете легко смоделировать параметры для тестирования. Используете ли вы инфраструктуру внедрения зависимостей? Если нет, то я бы порекомендовал вам программировать свои методы с использованием принципа Dependency Injection в любом случае для более модульного и легкого тестирования кода.

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