Вспомогательные методы модульного теста?

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

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

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

Обратите внимание, что этот подход изолирует вас от рефакторинга: вы можете изменить реализацию без изменения набора тестов (поскольку модульные тесты для вспомогательного объекта продолжают передать, даже если вспомогательный объект больше не является частью вашей производственной реализации), и вы получите чистую упаковку реализации и тесты для нее (вариант использования: вы решаете, что bozo-sort - неправильная реализация, и ее больше не следует использовать .Если реализация бозо-сортировки изолирована, вы просто удалите ее и ее тесты. Но когда тесты реализации бозо-сортировки запутываются со всеми другими тестами, требуется больше размышлений).

Это также может помогите понять, почему у вас есть модульные тесты для вашего кода. Если одна из причин "

Я довольно шокирован некоторыми ответами здесь.

В По сути, некоторые люди говорят: «Не тестируйте частный код, потому что это нарушает парадигму TDD»

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

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

/ ** Извините за это, но я унаследовал беспорядок ... * если вам нужно протестировать эти методы, укажите их в исходном коде и не комментируйте следующие * строки * /

Но ни в коем случае не позволяйте строгому соблюдению методологии разработки мешать улучшению кода.

Если вы хотите протестировать методы Helper , вы можете изменить их с частных, но вы можете подумать об этом.

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

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

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

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

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

В основном у вас есть 2 варианта:

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

2. Оставьте все как есть. Это помешает вам писать очень мелкие тесты, но не потребует от вас жертвовать какой-либо инкапсуляцией.

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

Есть третий вариант (который я m неохотно упоминает): используйте отражение (или какое-то другое колдовство) для вызова частных методов в вашем тестовом классе. Это имеет недостатки (1), а также недостатки, присущие рефлексивному коду (например, пропускает проверку типа и его трудно читать)

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

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

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

Вы не случайно определили общедоступный API в этом классе, верно? Проверьте это. Если это работает, класс работает.

Используйте инструменты покрытия кода, чтобы узнать, тестируется ли достаточная часть этого класса, а если нет, напишите дополнительные модульные тесты для проверки общедоступного API и попадите в те углы, которые не не покрывается.

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

Мое предпочтение состоит в том, чтобы проверить через публичное API объекта. Если это слишком сложно, то это намек на то, что объект должен быть разбит.