Я должен копировать тесты для перегрузок удобства?

" write two tests or is it better to assume that the convenience overloads have no logic of their own?"

Umm.... Your tests aren't defined by "assumptions". They're defined by the design of the class you're testing.

You don't do anything based on "assumptions".

If the convenience function is actually a convenience function, it must do the same thing and you must write a test that demonstrates that both variant methods actually do the same thing.

If "there could be different logic" (1) it isn't really a convenience function and (2) you must write a test that demonstrates that both variant methods actually do the correct thing (which may be the same with different logic, or may be different, I can't tell from the question.)

"MemberName_State_ExpectedResult. If I duplicate tests, then I have clashing names "

Avoid foolish consistency questions. If you have the same method with different signatures, then this naming convention isn't very good, is it? Sticking to it faithfully, in spite of it's problems, is a foolish consistency.

You can't trivially use this when you have methods that are distinguished only by argument signatures. So just make something up that works for all your convenience functions.

Обычно я делаю «настоящий» метод виртуальным . Это означает, что я могу протестировать удобный метод, используя производный класс для конкретного теста (обычно созданный с помощью динамического макета), чтобы убедиться, что он правильно вызывает «настоящий» метод.

Если единственная разница между «реальным» методом и Удобный метод - это использование значения по умолчанию для определенного параметра, вы можете покрыть это одним модульным тестом и двигаться дальше.

Я второй ответ С.Лотта относительно соглашения об именах.

Я часто не тестирую вспомогательные методы с таким же уровнем детализации, как основной метод, который они вызывают. Например, ваш случай ArgumentNullException. Я бы не стал проверять это дважды. Мне кажется, что модульное тестирование - это тестирование методом белого ящика. Мне разрешено знать реализацию.

Конечно, это может означать, что я обожгусь, когда пойду и займусь реорганизацией позже и добавлю функциональность к удобному методу. Но я неплохо делаю TDD (не полный фанат, как вы можете понять из первого абзаца). Так что я думаю, что, скорее всего, я бы написал тест для этой новой функциональности и затем рассмотрел его.

Я не утверждаю, что это более или менее правильно. Я просто так делаю.

Если все ваши конструкторы вызывают полностью указанный конструктор, я бы разбил тесты на
1) ваш текущий модульный тест, который должен иметь вид
ConstructorShouldDoThisAndThat ()
2) специализированные модульные тесты для перегрузок, определяющие, какой по умолчанию используется перегрузка, например ConstructorWithNoEncodingShouldSetEncodingToDefaultEncoding ()

Думаю, ответ проще, чем вы думаете: вас волнует, работают ли перегруженные методы или нет? Если вам небезразлично, что они работают, как вы узнаете наверняка, если не протестируете их?

Вам потребуется около 15 секунд, чтобы написать тест, который сравнивает выходные данные перегруженной функции с той, которую она перегружает. Сделай это и двигайся дальше.