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; 
} 

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Я предлагаю двигаться эту функцию ведущего объекта, что-то вроде

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

Легче проверить, и более OO-подобный код =)

Answer 3

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

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