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

Итак, мы с коллегой находимся в довольно жарком споре. Мы начинаем новый проект и пытаемся использовать 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;
}

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

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

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

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


unit-testing mocking tdd specifications bdd
person Kevin Wiskia    schedule 27.01.2010    source источник
comment
Что ж, конечно, бинарные диаграммы решений великолепны, но они не последняя вещь последнего поколения, которая делает все, что мы знали, устаревшим... О, подождите, неважно.   -  person Pascal Cuoq    schedule 27.01.2010

Ответы (3)


arrow_upward
3
arrow_downward

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

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

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

person Martin R-L    schedule 17.02.2010
comment
Это своего рода маршрут, по которому мы в итоге пошли. Он отлично работает. - person Kevin Wiskia; 22.02.2010
comment
Супер :-) Мы тоже ценим этот метод все больше и больше. - person Martin R-L; 22.02.2010

arrow_upward
8
arrow_downward

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

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

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

Легче тестировать и больше похож на объектно-ориентированный код =)

person Samuel Carrijo    schedule 27.01.2010

arrow_upward
2
arrow_downward

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

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

person Alex Baranosky    schedule 27.01.2010