Это хорошая практика, чтобы написать UnitTests для System.NotImplementedException / System.NotSupportedException

Question

Это хорошая практика, чтобы написать UnitTests для System.NotImplementedException / System.NotSupportedException

2

Я реализую набор интерфейсов из сторонней библиотеки. Я не хочу поддерживать все функции, определенные в интерфейсах, поэтому я бросаю System.NotImplementedException/System.NotSupportedException для не поддерживаемых функций.

Должен ли я писать Unit-тесты для фрагмента кода, который генерирует исключение? Это нормально, если я пишу тесты?

user 7979913 01 окт. 2018, в 09:22

Источник

1

NotSupportedException обычно подразумевает, что «эта реализация никогда не будет поддерживать эту функцию», поэтому UT для документирования этого факта представляется целесообразным. NotImplementedException обычно означает «я еще не успел его реализовать», поэтому я бы не подумал, что вам понадобится UT, который ожидает это исключение.
Joe 01 окт. 2018, в 06:45
0

«Я не хочу поддерживать все функции, определенные в интерфейсах». Тогда вам не следует реализовывать это. Нет смысла в реализации интерфейса только в меру.
HimBromBeere 01 окт. 2018, в 06:46
0

@HimBromBeere - есть ситуации, в которых целесообразно частично реализовать интерфейс (и обычно NotSupportedException где это уместно. Например, ReadOnlyCollection<T> реализует ICollection<T>.Add , выбрасывая NotSupportedException .
Joe 01 окт. 2018, в 06:49
0

@Joe Только потому, что они существуют, не означает, что это хорошая идея. Я всегда чувствовал IRadonlyCollection.Add странно.
HimBromBeere 01 окт. 2018, в 06:52
0

@HimBromBeere - это было бы еще более странно и менее удобно, если бы ReadOnlyCollection<T> не реализовал ICollection<T> . В документации для NotSupportedException приводится еще один пример: «Вы реализуете интерфейс общего назначения, а у ряда методов нет значимой реализации. Например, если вы создаете тип даты и времени, который реализует интерфейс IConvertible, вы бы бросили NotSupportedException исключение для большинства конверсий. "
Joe 01 окт. 2018, в 06:54
0

Как показывает опыт работы с TDD, я должен сначала написать модульный тест, тогда все функции NotImplementedException поэтому, по моему мнению, я бы хотел использовать NotSupportedException
Tu Tran 01 окт. 2018, в 07:05

Показать ещё 4 комментария

Теги:

c#

unit-testing

exception-handling

1 ответ

Ещё вопросы

NotSupportedException обычно подразумевает, что «эта реализация никогда не будет поддерживать эту функцию», поэтому UT для документирования этого факта представляется целесообразным. NotImplementedException обычно означает «я еще не успел его реализовать», поэтому я бы не подумал, что вам понадобится UT, который ожидает это исключение.
«Я не хочу поддерживать все функции, определенные в интерфейсах». Тогда вам не следует реализовывать это. Нет смысла в реализации интерфейса только в меру.
@HimBromBeere - есть ситуации, в которых целесообразно частично реализовать интерфейс (и обычно NotSupportedException где это уместно. Например, ReadOnlyCollection<T> реализует ICollection<T>.Add , выбрасывая NotSupportedException .
@Joe Только потому, что они существуют, не означает, что это хорошая идея. Я всегда чувствовал IRadonlyCollection.Add странно.
@HimBromBeere - это было бы еще более странно и менее удобно, если бы ReadOnlyCollection<T> не реализовал ICollection<T> . В документации для NotSupportedException приводится еще один пример: «Вы реализуете интерфейс общего назначения, а у ряда методов нет значимой реализации. Например, если вы создаете тип даты и времени, который реализует интерфейс IConvertible, вы бы бросили NotSupportedException исключение для большинства конверсий. "
Как показывает опыт работы с TDD, я должен сначала написать модульный тест, тогда все функции NotImplementedException поэтому, по моему мнению, я бы хотел использовать NotSupportedException

Ralf Bönning · Answer 1 · 2018-10-01T04-21-00.000Z

Вполне нормально записывать модульные тесты, проверяющие NotSupportedExceptions в реализациях частичного интерфейса. Сделав это, вы задокументируете, что это желаемое поведение реализации. Если кто-то воспользуется этим методом позже, он должен отрегулировать unit тест и должен -at least- подумать, если это новое желаемое поведение системы.