Куда вы кладете юнит-тесты для приватных методов?

Question

Где вы размещаете модульные тесты для частных функций в классах C #?

Статья в Википедии предлагает:

• Помещение тестов в тот же класс, что и тестируемые члены
• Использование частичных классов

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

Есть мысли по этому поводу?

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

Answer 1

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

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

Редактировать: Что касается того, где должны располагаться другие ваши тесты, я предлагаю отдельный подкаталог в вашем проекте для обработки ваших тестов. При написании тестов для PHP-приложений у меня есть каталог tests в корне моего проекта, структура каталога которого идентична структуре моей реальной структуры каталога приложения. В нем у меня есть тестовый класс для каждого реального класса.

Просто не компилируйте свои тестовые классы с остальной частью вашего проекта при выпуске в производство (или в случае интерпретируемого языка, такого как PHP, не развертывайте тестовые классы на рабочем веб-сервере).

Answer 2

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

[assembly: InternalsVisibleTo("MyAssembly.UnitTests")]

Answer 3

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

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

Где вы размещаете модульные тесты для частных функций в классах C #?

Nowhere. Их не существует.

В общем, мои юнит-тесты находятся в отдельных проектах.

Answer 4

Вы должны делать то, что работает для вас; вот что работает для меня:

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

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

Мои классы, как правило, довольно маленькие . Их легко читать и понимать. Мои методы, конечно, тоже очень маленькие и их легко понять.

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

Answer 5

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

Тем не менее, есть причины, по которым вы можете захотеть протестировать частные методы:

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

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

Некоторые решения:

1. Объявите некоторые общедоступные методы, которые делегируют приватному методу и используются только для целей тестирования. Это может быть префикс, например, с TestFoo1, TestFoo2 и т. д.

2. Использовать внутренний

http://msdn.microsoft.com/en-us/library/7c5ka91b(VS.80).aspx

Answer 6

Мы используем частные средства доступа в Visual Studio для тестирования частных методов. Это означает, что тестовые классы могут жить в отдельном проекте.

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

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

Answer 7

абсолютно да. частные методы должны быть проверены в любом случае. и mbunit платформа модульного тестирования может получить доступ к приватному члену.

см. Этот блог: тестирование частных методов

Answer 8

Ваше название вопроса и первое предложение отличаются. :)

Я не уверен, где разместить ваши тесты. Это зависит от языка, и C # - это не то, с чем я знаком, но я думаю, что значительная часть вашего кода находится внутри частных методов. Я чувствовал бы себя неловко, если бы это не было проверено. Покрытие кода значительно уменьшится.