Можно ли изменить видимость метода для модульного тестирования?

Много раз я разрывался между тем, чтобы сделать метод приватным, чтобы кто-то не вызывал его в контексте, который не имеет смысла (или будет нарушать внутреннее состояние объекта) или сделать этот метод общедоступным (или обычно внутренний), чтобы выставить его на узел unit test. Мне было просто интересно, что думает об этом переполнении Stack Overflow?

Итак, я думаю, что на самом деле вопрос: лучше ли сосредоточиться на тестируемости или на поддержании правильной инкапсуляции?

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

Ответ 1

Это зависит от того, является ли этот метод частью публичного API или нет. Если метод не относится к части публичного API, но он называется публично из других типов в рамках одной и той же сборки, используйте внутреннюю, друга свою сборку unit test и unit test.

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

Это плохой тип связи, увеличивает количество единичных тестов, которые вам нужны, увеличивает нагрузку как в краткосрочной перспективе (больше модульных тестов), так и в долгосрочной перспективе (более тесное обслуживание и модификация в ответ на реорганизацию внутренней реализации Детали). Еще одна проблема с тестированием непубличных участников заключается в том, что вы проверяете код, который на самом деле не нужен или не используется. БОЛЬШОЙ способ найти мертвый код - это когда он не охвачен ни одним из ваших модульных тестов, когда ваш открытый API покрыт 100%. Удаление мертвого кода - отличный способ сохранить базу кода скудным и средним, и это невозможно, если вы не будете осторожны в том, что вы вложили в свой публичный API, а какие части вашего кода вы unit test.

EDIT: В качестве дополнительной дополнительной заметки... с правильно разработанным общедоступным API вы можете очень эффективно использовать инструмент, например Microsoft PEX, чтобы автоматически генерировать полный охват которые проверяют каждый путь выполнения вашего кода. В сочетании с несколькими вручную написанными тестами, которые охватывают критическое поведение, все, что не охвачено, можно считать мертвым кодом и удалено, и вы можете значительно сократить процесс тестирования устройства.

Ответ 2

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

Вы используете С# да? Проверьте внутренности, видимые для класса атрибутов. Вы можете объявить свои тестируемые методы внутренними и позволить вашему модулю тестировать сборку для ваших внутренних компонентов.

Ответ 3

Это общая мысль.

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

Ответы на этот вопрос (Java) и этот вопрос (.NET) должны быть полезны.

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

Ответ 4

В общем, я согласен с @jrista. Но, как обычно, это зависит.

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

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

Итак, для устаревшего кода сделайте то, что вам нужно сделать.

Ответ 5

В .NET вы должны использовать Accessors для модульного тестирования, даже не атрибут InternalsVisibleTo. Аксессоры позволяют получить доступ к любому методу в классе, даже если он является приватным. Они даже позволяют тестировать абстрактные классы, используя пустой производный объект (см. Класс "PrivateObject" ).

В основном в вашем тестовом проекте вы используете класс accessor, а не фактический класс, с методами, которые вы хотите проверить. Класс accessor аналогичен классу "real", за исключением того, что все доступно для вашего тестового проекта. Visual studio может создавать для вас аксессоры.

НИКОГДА не делайте тип более видимым, чтобы облегчить модульное тестирование.

IMO НЕПРАВИЛЬНО сказать, что вы не должны unit test частные методы. Единичные тесты имеют исключительное значение для регрессионного тестирования, и нет причин, по которым частные методы не должны подвергаться регрессионной проверке с помощью гранулированных модульных тестов.