Стоит ли тестировать частные методы или только публичные?

Question

Я прочитал этот пост о том, как тестировать частные методы. Я обычно не проверяю их, потому что всегда думал, что быстрее тестировать только публичные методы, которые будут вызываться извне объекта. Вы тестируете частные методы? Должен ли я всегда проверять их?

Answer 1

Мы тестируем частные методы с помощью логического вывода, под которым я подразумеваю, что мы ищем общий охват тестов класса, по крайней мере, на 95%, но наши тесты только обращаются к открытым или внутренним методам. Чтобы получить покрытие, нам нужно сделать несколько звонков для общественности / внутренних органов в зависимости от возможных сценариев. Это делает наши тесты более внимательными к цели кода, который они тестируют.

Ответ Трампи на пост, на который вы ссылаетесь, самый лучший.

Answer 2

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

Answer 3

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

Answer 4

Я какое-то время пытался решить эту проблему, особенно когда попробовал свои силы в TDD.

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

1. Тестирование частных методов, TDD и тест-рефакторинг
2. Разработка, управляемая тестом, не тестирует

---

В итоге:

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

• По самой природе процесса любой бит простой функциональности реализации, извлеченный из тщательно протестированной функции, будет самотестирован (т.е. охват косвенным тестированием).

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

Поэтому эти методы будут общедоступными, и их тестирование будет достаточно простым.

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

Answer 5

Как указано выше: «Если вы не тестируете свои частные методы, откуда вы знаете, что они не сломаются?»

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

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

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

Итак, в общем, да, юнит-тестирование ваших частных методов.

Answer 6

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

Answer 7

Если вы не тестируете свои личные методы, откуда вы знаете, что они не сломаются?

Answer 8

Очевидно, что это зависит от языка. В прошлом с c ++ я объявил класс тестирования своим классом. К сожалению, для этого требуется, чтобы ваш производственный код знал о классе тестирования.

Answer 9

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

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

Так почему же мы тестируем объекты? Поскольку это действительно трудно, нельзя сказать невозможно, быть уверенным, что мы тестируем методы контроллеров с соответствующим вводом, который будет запускать все ветви базового кода. Другими словами, чем выше мы в стеке, тем сложнее проверить все поведение. И то же самое для частных методов.

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

• метод вызывается более одного раза из разных мест?
• Является ли метод достаточно сложным, чтобы требовать испытаний?

Answer 10

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