Данные насмешки BDD/TDD хитрый путь
Таким образом, коллега и я находимся в довольно горячем споре. Мы начинаем новый проект, и мы пытаемся использовать BDD. Мы - оба новички и не полностью понимаем, какие методы должны использоваться. Мы записали некоторые спецификации, и мы теперь реализуем код. Вещи становятся довольно хитрыми, так как существует большое взаимодействие базы данных. Мы застреваем о том, как мы должны дразнить наши данные. Метод, о котором мы шли, потребует, чтобы мы дразнили наши методы вместо наших данных. Является самым легким, если я показываю Вам в коде...
public static void AssignLeadToDistributor(int leadId, int distributorId)
{
Lead lead = GetById(leadId);
lead.DistributorId = distributorId;
Save(lead);
}
В основном мы должны были бы переопределить GetById () и Сохранить () для возврата ложных данных для нас для тестирования этого. Это, кажется, имеет больше смысла делать это как это:
public static void AssignLeadToDistributor(Lead lead, Distributor distributor)
{
lead.DistributorId = distirbutor.Id;
}
Затем мы могли просто дразнить наши объекты.
Очевидно второй метод помогает протестировать. Однако аргумент - то, что мы не хотим должными быть выбирать новый вывод и объект дистрибьютора на нашем коде фронтэнда, потому что было бы легче просто передать идентификаторы наших объектов. Сокращение фактического кода в нашем фронтэнде.
Надо надеяться, я объяснил это достаточно хорошо.
Что делает Вас, парни думают? Какой путь имеет больше смысла?
3 ответа
- Обязательно используйте API трассировки/регистрации для получения диагностической информации. Журнал событий, файлы журнала, база данных, что угодно... Просто получите информацию об устранении неполадок где-нибудь.
- Трассировка/Регистрация выполняется рано и часто. Ничто больше не расстраивает то, что нужно сделать изменение кода, которое просто добавить диагностическую трассировку.
- Осознавать утечку памяти. При написании приложения, которое будет перезапускаться каждый день или запускаться как запланированная задача, иногда мы получаем немного лень. Помните, что эта служба должна тщательно убирать после себя. Правильно используйте предложение using со всеми IDisposables.
- Не забудьте ключевое слово volatile в переменной STOP! Боже мой, это доставляет меня каждый раз.
Если это имеет смысл, не забудьте реализовать событие Pause. Обработайте все исключения, чтобы отказать изящно.
-121--1525774-Что мы делаем в наших спецификациях BDD (исполняемые истории), так это не издеваться над БД вообще, а вместо этого использовать БД в памяти (SQLite в нашем случае).
Кроме того, мы инициализируем контейнер перед запуском любого сценария. Это потому, что мы хотели бы, чтобы наши спецификации BDD имитировали реальный мир, насколько это возможно, при этом все еще имея скорость обычных единичных тестов.
Определив наши спецификации BDD таким образом, мы обнаружили, что потребность в единичных тестах и интеграционных тестах уменьшается, и получили как повышенную производительность, так и понятность (хотя и очень субъективную, так как вы не можете измерить эти показатели).
Мне нравится второй метод лучше, по причине вы указали: вы можете издеваться Параметры легко для тестирования. Вы используете структуру впрыска зависимости? Если нет, то вы, я бы порекомендую вам программу программировать ваши методы, используя принцип впрыска зависимостей в любом случае для более модульного и простого в тестовом коде.
И я согласен с Samuel, который вам нужно избегать использования статических методов, когда это возможно, или вы найдете его очень сложно, чтобы проверить их.
Я думаю, что самая большая проблема, которую у вас есть, потому что вы используете публичные статические функции (что обычно является плохой вещью в языках OO).
Я бы предложил переместить эту функцию к ведущему объекту, что-то вроде
public AssignDistributor(int distributorId) {
this.DistributorId = distributorId;
this.Save();
}
проще тестировать, и более oo-подобный код =)