Создание функции сопоставления с помощью TDD:Слишком много времени потрачено на написание тестов?
-
21-09-2019 - |
Вопрос
Я большой энтузиаст TDD и всегда стремлюсь писать тесты перед написанием рабочего кода, чтобы гарантировать правильное поведение кода, который я пишу.Однако иногда возникает вопрос, разумно ли писать большое количество тестов для определенных типов методов.Кажется, это чаще всего возникает при написании класса картографа.
public class FooBarMapper
{
public Foo MapToFoo(Bar bar)
{
return new Foo
{
Id = bar.Id,
Name = bar.Name,
FooYuk = bar.Beverage,
/* ... */
};
}
}
Скажем, например, что есть около дюжины свойств, которые можно сопоставить выше.В среде TDD, прежде чем писать какие-либо сопоставления, я бы, вероятно, написал тест.Что-то вроде MapToFooMapsBeverageToFooYuk()
.Тест не пройден, и мне приходится писать код, чтобы он прошел.Я повторяю это для каждого свойства, которое необходимо сопоставить.Вопрос в том:Не заводит ли это разработку с приоритетом тестирования слишком далеко?Лично я так не думаю, поскольку предпочел бы иметь полный набор тестов, точно говорящих мне, что именно делает код, но я хотел бы услышать, что думает сообщество.
Решение
Даже дядя Боб Мартин, ярый защитник TDD и всего, что связано с TDD, говорит, что вам не нужно писать модульные тесты для каждого тривиального свойства (тривиальное свойство определяется как свойство, которое просто получает и устанавливает переменную-член).
Если вы когда-нибудь напишете свойство, имеющее побочные эффекты (в чем я сомневаюсь), затем вы можете добавить к нему модульный тест.Как отмечает ДаффиМо, если ваши объекты недвижимости охвачены функциональным тестированием, в модульных тестах не должно быть необходимости, поскольку нет Спецификация функциональности, которую вы определяете с помощью модульного теста, кроме тривиального get/set.
Другие советы
Может быть, это то, что Фитнессе был рожден для.
В этом случае я бы написал один тест, который проверяет все тривиальные свойства одновременно.Это не совсем стандартный способ решения задач, но со временем тесты для отдельных тривиальных свойств, вероятно, будут преобразованы в единый тест для всех свойств.Поскольку свойства тривиальны, я предлагаю начать с теста, которым вы бы закончили.
После сопоставления первых трех свойств я видел дублирование и заменял его, перебирая свойства и присваивая их с помощью отражения.Для этого нужно всего лишь несколько тестов:0 свойств, 1 свойство, 5 свойств, целевой объект не имеет ожидаемых свойств, исходный объект не имеет ожидаемых свойств.Теперь я могу повторно использовать этот общий картографический механизм повсюду во всех своих приложениях, и мне не нужно проверять его каждый раз, когда я его использую.