Методы тестирования, вызванные другим методом

Question

У меня есть класс с методом DataIn(int InputID, string CSVValue), это основная точка входа в него.

Этот метод, основанный на InputID, сохраняет параметр значения CSV в соответствующем List<string>'s. Когда InputID совпадает с свойством NoOfRows, он создает один List<string>, составленный из всех остальных. Затем он проверяет достоверность этого окончательного List<string>, если все в порядке, то он добавляет результаты в HashSet<int> в качестве быстрого способа проверки дубликатов.

Я сломал эту логику на 3 метода, поэтому DataIn вызывает StoreData, когда InputID в DataIn = NoOfRows вызывает MergeData, который вызывает ValidateData.

Мой вопрос заключается в том, следует ли публиковать эти методы для их проверки отдельно, или я должен хранить их конфиденциальными и передавать данные DataIn, а также делать подтверждения для объединенных данных List<string> и HashSet<int>. DataIn будет методом, который вызывается извне класса, что делает другие методы общедоступными только для модульного тестирования.

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

Каков ваш совет?

Answer 1

Всегда придерживайтесь principle of least privilege. Предоставление частных методов как публичных, чтобы сделать их единым тестируемым, не является хорошим дизайном. Вместо этого придерживайтесь только теста public interfaces. Если метод ведет себя по-разному с разными входами, убедитесь, что вы пишете тест на поведение, ожидаемое, и вы должны иметь чистый и чистый дизайн, при этом все еще хорошо тестироваться.

Answer 2

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

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