Вы определенно должны проверять защищенные методы. С точки зрения тестирования «защищенный» метод все еще является частью открытого интерфейса, хотя «общественность» ограничена теми классами, которые происходят из вашего класса. Поскольку код, который вы не контролируете, может ссылаться на эти методы, вы должны убедиться, что они функционируют как определенные.
Что касается повторяющихся испытаний, у меня нет окончательного ответа. Если Дано:
public class A
{
protected virtual void Foo() {}
}
public class B:A
{
}
вопрос, пишут ли вы тест на B.Foo. С одной стороны, я бы сказал «нет», потому что B не содержит явной реализации Foo, поэтому его поведение не может отличаться от поведения A.Foo, и мы можем предположить, что вы уже протестировали A.Foo.
С другой стороны, A.Foo может зависеть от некоторых других protected полеев или свойств, которые B могут изменять, или на частный обратный вызов, который B обеспечивает в конструкторе или инициализации функции. В этом случае вам абсолютно необходимо проверить B.Foo, потому что его поведение может быть отличным от A.Foo, хотя B не переопределяет A.Foo.
Очевидно, что если B переопределяет Foo, вам необходимо написать тест для B.Foo. Но если B не переопределяет A.Foo, тогда вы должны использовать свое мнение.
Все, что сказано, это ничем не отличается от необходимости писать тесты для любого класса, который происходит от другого. Рассмотрим вывод класса из TextWriter. Не могли бы вы написать явные модульные тесты для всех виртуальных функций, определенных классом TextWriter? Или вы пишете тесты только для тех методов, которые вы переопределяете, и тех методов, функциональность которых может измениться как побочный эффект?
A (не обязательно лучший) способ состоит в том, чтобы получить класс и обеспечить хорошо известное поведение в этом классе. Все, что вы сейчас тестируете, - это базовый класс. Хорошо известное поведение необходимо избегать тестирования тестового класса или его интеграции при его получении в реальных классах. – Samuel
Я думаю, вы захотите дублировать свои тесты для каждого производного класса. Представьте, что кто-то меняет один производный класс, чтобы больше не использовать защищенный метод. Если вы явно не проверяете каждый производный класс, даже если они имеют одинаковое поведение, вы не заметите, что этот тип изменений происходит. – juharr