Создание функции отображения через TDD: слишком много времени уходит на написание тестов?

Question

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

public class FooBarMapper
{
    public Foo MapToFoo(Bar bar)
    {
        return new Foo
        {
            Id = bar.Id,
            Name = bar.Name,
            FooYuk = bar.Beverage,
            /* ... */
        };
    }
}

Скажем, например, что существует около дюжины свойств для сопоставления с вышеупомянутыми. В среде TDD, прежде чем писать какие-либо сопоставления, я бы, вероятно, написал тест. Что-то вроде MapToFooMapsBeverageToFooYuk(). Тест не пройден, что привело меня к написанию кода для его прохождения. Я повторяю это для каждого свойства на карте. Вопрос в том, слишком ли далеко заходит разработка, основанная на тестах? Лично я так не думаю, так как предпочел бы полный набор тестов, рассказывающих мне точно, что делает код, но я хотел бы услышать, что думает сообщество.

Answer 1

Даже дядя Боб Мартин, убежденный защитник TDD и всех вещей TDD, говорит, что вам не нужно писать модульные тесты для каждого тривиального свойства (тривиальное свойство определяется как свойство, которое просто получает и устанавливает переменную-член ).

Если вы когда-нибудь напишите свойство, которое имеет побочные эффекты (что, я сомневаюсь, у вас будет), , то вы можете добавить к нему модульный тест. Как указывает DuffyMo, если ваши свойства охватываются функциональным тестированием, не должно быть необходимости в модульных тестах, поскольку не существует спецификации функциональности, которую вы определяете с помощью модульного теста, кроме тривиального get / установлен.

Answer 2

После сопоставления первых трех свойств я увидел бы дублирование и заменил бы его, перебирая свойства и назначая их с помощью отражения. Для этого требуется всего несколько тестов: 0 свойств, 1 свойство, 5 свойств, целевой объект не имеет ожидаемых свойств, исходный объект не имеет ожидаемых свойств. Теперь я могу использовать этот общий механизм картирования везде во всех моих приложениях, и мне не нужно проверять его каждый раз, когда я его использую.

Answer 3

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

Answer 4

Может быть, для этого и родился FitNesse .