Должен ли я тестировать базовый метод?

Question

У меня есть два класса

public abstract class BaseClass 
{ 
    public string PropertyA {get; set;} 

    public virtual object CopyProperties(BaseClass other) 
    { 
    other.PropertyA = this.PropertyA; 
    } 
} 

и класс, который наследует от нее

public class ChildClass : BaseClass 
{ 
    public string PropertyB {get; set;} 

    public virtual object CopyProperties(BaseClass other) 
    { 
    other.PropertyB = this.PropertyB; 
    base.CopyProperties(other); 
    } 
} 

Естественно я блок испытанный такой сложной логики!

У меня есть два теста:

Ensure_calling_CloneProperties_copies_PropertyA() Ensure_calling_CloneProperties_copies_PropertyB()

Я хочу знать, является ли также требуется следующее испытание

Ensure_calling_CloneProperties_on_ChildClass_calls_base()

Мое личное мнение заключается в том, что мы должны проверить поведение CloneProperties на ChildClass, нам нужно проверить, что при вызове clone PropertyA и PropertyB оба скопированы правильно - нам не нужно (или хотите) знать, как это происходит достигнуты. Однако коллега не согласен.

Учитывая гибкие и лучшие методы TDD, я должен также создать третий тест?

Answer 1

Я согласен с Вашим мнением. Важное значение имеет поведение метода, а не его работа. Даже в том, что касается тестирования взаимодействия, «взаимодействие» между классом и его базовым классом не является «интересным» с точки зрения поведения системы. Если (скажем) свойство A копирование было выполнено первоначально в базовом классе, и вы удалили эту функциональность из Base, ваш тест на копирование свойств обнаружит этот сбой, так что, насколько регрессия, ваш набор тестов охватывает то, что важно. Если копирование свойств было перемещено с базы на дочерний (или наоборот), тест не будет сообщать об отсутствии регрессии - и ваша система будет вести себя корректно.

Answer 2

Я также предложил бы рассмотреть возможность реорганизации вашего кода, так что есть нет наследования. Проверить это "inheritance vs composition" нити для более подробной информации.

В этом случае можно вводить текущую „функциональность базового класса“ и обеспечить ваше испытание ChildClass не имеет зависимости от кода в BaseClass

Когда вы пишете тест блока (который вы делаете в TDD), вы проверяете только этот класс. В вашем примере проверка того, что BaseClass.CopyProperties была вызвана с определенным параметром, предпочтительнее, чем проверка, которая обращается к PropertyA, потому что, если вы меняете базовый класс, - но они не должны.

Еще одна идея может заключаться в том, чтобы отделить BaseClass от ChildClass полностью - через событие. BaseClass может подписаться на конкретное событие ChildClass и сделать все, но ваш тестовый код будет еще более чистым, так как все, что вы проверяете, - это то, что установлено ProperyB, и событие уволено.