Требуется ли модульное тестирование аксессуаров?

Ответ 1

Совершенно верно. Идея модульных тестов заключается в том, чтобы гарантировать, что изменения не влияют на поведение неизвестными способами. Вы можете сэкономить некоторое время, не написав тест для getFoo(). Если вы измените тип Foo, чтобы быть чем-то более сложным, вы можете легко забыть протестировать аксессуар. Если вы спрашиваете, следует ли вам писать тест или нет, вам лучше написать его.

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

Хорошая мантра - это всегда добавлять тесты. Если вы не думаете, что вам это нужно, потому что метод тривиален, попробуйте удалить этот метод. Я понимаю, что общий совет заключается в том, что можно пропустить тесты для "тривиальных" методов, но вы должны спросить себя, нужен ли этот метод. Если вы пропустите тест, вы говорите, что метод всегда будет тривиальным. Помните, что модульные тесты также функционируют как документация о намерениях и предлагаемом контракте. Следовательно, тесты тривиального метода показывают, что метод действительно должен быть тривиальным.

Ответ 2

Я бы только unit test их, если они делают больше, чем задают или возвращают переменную. В какой-то момент вам нужно верить, что компилятор будет генерировать нужную вам программу.

Ответ 3

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

Ответ 4

Вам не нужно писать тест для свойств, которые не содержат логики.

Единственное объяснение для проверки простых свойств - повысить охват тестированием - но это просто глупо.

Ответ 5

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

В то время как 100% охват тестирования - замечательный идеал, в какой-то момент вы сталкиваетесь с уменьшающейся отдачей, когда время, потраченное на проведение теста, не стоит того, что вы получаете от него.

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

Ответ 6

В нашей компании есть как люди, так и мнения. Я стараюсь не тестировать их конкретно, поскольку они обычно

• автоматически сгенерировано
• тестируется в контексте другого теста (например, есть еще один код, использующий эти аксессоры
• не содержит никакого кода, который может сломаться

Есть исключения:

• Когда они не просто сгенерированы "getters" и "seters"
• Когда они являются частью важного API, который только что предоставлен для других пользователей и не протестирован в контексте, который вы в настоящее время находитесь в

Оба эти случая могут заставить меня проверить их. Первый - больше второго.

Ответ 7

Нет! Отходы времени!

Даже Боб Мартин Смотрите SO подкаст 41, дед Agile говорит, что нет.

Ответ 8

Если ваша среда IDE генерирует и управляет модификациями для доступа к элементам-кандидатам - вы не будете делать что-то особенное --- тогда тестирование их действительно не важно; типы будут совпадать, именование будет по шаблону и т.д.

Ответ 9

Я думаю, что большинство людей скажут, что тестирование их - пустая трата времени. В 99% случаев это верно. Если ошибка в аксессуре и остальных модульных тестах не поймает его косвенно, я начну спрашивать, почему это свойство существует вообще.

С другой стороны, тестирование аксессора требует меньше ввода, задающего этот вопрос:)

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

Ответ 10

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

• Является ли getter/setter доступ к чему-либо на DAL (уровень доступа к данным)?

Если это так, я бы включил unit test. На всякий случай, потому что, если в какой-то момент в будущем вы решите реализовать ленивую загрузку или что-то более продвинутое, чем простой get/set, вам нужно убедиться, что это работает правильно.

2. Возможно ли, что getter/setter генерирует исключение?

Лучшая практика для геттеров - не позволить им вообще бросать исключения. Сеттер - другое дело. Однако в любом случае, если вы решите, что свойство может вызвать исключение, напишите unit test для этого свойства как для успешного доступа, так и для целенаправленного создания исключения.

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

Ответ 11

Мне нравится иметь модульные тесты для них. Если аксессуар выполняет какую-либо работу, кроме как просто возвращает поле, тогда этот код будет проверен соответствующим образом.

Даже если данный аксессуар не делает ничего, кроме возврата поля, он может быть изменен позже, чтобы сделать что-то дополнительное.

Кроме того, это простой способ увеличить количество выполняемых тестов, что нравится многим менеджерам.