Где вы размещаете модульные тесты для частных методов?
Где вы размещаете модульные тесты для частных функций в классах C#?
Статья в Википедии предлагает:
- Помещение тестов в тот же класс, что и члены, которые они тестируют
- Использование частичных классов
Лично ни один из этих методов не кажется подходящим, и я очень предпочитаю, чтобы модульные тесты располагались в отдельном проекте.
Есть мысли по этому поводу?
(Я знаю, что есть много споров о том, следует ли вообще тестировать частные методы. Я хотел бы услышать обе стороны аргумента.)
8 ответов
Частные методы не обязательно должны быть проверены напрямую. Вы можете определить их достоверность на основе тестов открытых методов, которые используют эти частные методы.
Однако вы должны позаботиться о том, чтобы ваши публичные методы могли легко вводить фиктивные зависимости в ваши частные методы, чтобы упростить тестирование и моделировать все разумные сценарии.
Изменить: Что касается того, где должны быть расположены другие ваши тесты, я предлагаю отдельный подкаталог в вашем проекте для обработки ваших тестов. Когда я пишу тесты для приложений PHP, у меня есть каталог tests в корне моего проекта, структура каталогов которого идентична структуре моей реальной структуры приложений. В нем у меня есть тестовый класс для каждого реального класса.
Просто не компилируйте свои тестовые классы с остальной частью вашего проекта при выпуске в производство (или в случае интерпретируемого языка, такого как PHP, не развертывайте тестовые классы на производственном веб-сервере).
Не проводите модульное тестирование частных методов. Модульные тесты предназначены для тестирования видимого (общедоступного и защищенного) интерфейса класса. Закрытые методы являются деталями реализации, и для них нет необходимости писать модульные тесты (их поведение должно быть неявно проверено тестами видимых методов), что приводит к хрупким тестам (поскольку детали реализации могут измениться) и является препятствием для рефакторинга.
Если у вас есть закрытый метод, который, по вашему мнению, вам необходим для модульного тестирования, это большой намек на то, что, возможно, его следует включить в публичный метод другого класса.
Где вы размещаете модульные тесты для частных функций в классах C#?
Нигде. Их не существует
В общем, мои юнит-тесты находятся в отдельных проектах.
Мне также нравится проводить модульные тесты в отдельном проекте. Если вы хотите выполнить модульное тестирование приватного метода, вы можете вместо этого сделать приватный метод внутренним. Затем вы можете сделать внутренние методы видимыми для ваших модульных тестов для непосредственного вызова, добавив следующее в AssemblyInfo.cs:
[assembly: InternalsVisibleTo("MyAssembly.UnitTests")]
Вы должны делать то, что работает для вас; вот что работает для меня:
Мой юнит - это класс: это то, что я пытаюсь проверить. Не метод. Я пытаюсь заниматься объектно-ориентированным программированием, поэтому я уделяю внимание объектам.
Если я испытываю желание проверить приватный метод, мне нужно провести рефакторинг. Я только хочу протестировать приватный метод напрямую, потому что между ним и тестами слишком много другого кода, и потому что сам приватный метод достаточно сложен, чтобы требовать тестирования. Поэтому я обычно извлекаю Class, чтобы вывести этот закрытый метод и другие связанные члены в новый класс.
Мои занятия, как правило, довольно маленькие. Их легко читать и понимать. Мои методы, конечно, тоже очень маленькие и их легко понять.
Переход к такому способу работы потребовал от меня переосмысления многих моих предположений и привычек в отношении программирования. То, что когда-то казалось радикальным, теперь кажется банальным.
Я согласен с тем, что частные методы вообще не должны тестироваться, потому что вы должны тестировать только открытые интерфейсы.
При этом есть причины, по которым вы можете захотеть протестировать частные методы:
Вы используете TDD, и вам нужно разработать сложный частный метод. Создание методов тестирования для частного метода может быть необходимо для поддержания правильной детализации вашего кода записи-тестирования-цикла тестирования.
Вы можете быть частью команды, в которой другим может потребоваться изменить приватный метод, и вам нужны тесты, чтобы убедиться, что изменения не создают проблем.
Некоторые решения:
Объявите некоторые общедоступные методы, которые делегируют приватный метод и используются только для целей тестирования. Это может быть префикс, например, с TestFoo1, TestFoo2 и т. Д.
Используйте внутренний
http://msdn.microsoft.com/en-us/library/7c5ka91b(VS.80).aspx
Мы используем частные средства доступа в Visual Studio для тестирования частных методов. Это означает, что тестовые классы могут жить в отдельном проекте.
Тем не менее, мы стараемся действительно ограничить их количество, потому что:
- закрытый метод, который может стоять отдельно, может быть извлечен как открытый метод в другом классе
- частные методы, которые не делают ничего особенно полезного за пределами класса, можно проверить с помощью открытых методов этого класса.
Абсолютно да. частные методы должны быть проверены в любом случае. и модульный тестовый модуль mbunit может получить доступ к приватному члену.
посмотрите этот блог: тестирование приватных методов
Ваше название вопроса и первое предложение разные.:)
Я не уверен, где разместить ваши тесты. Это будет зависеть от языка, и C# - это не то, с чем я знаком, но я думаю, что значительная часть вашего кода находится внутри приватных методов. Я чувствовал бы себя неловко, если бы это не было проверено. Покрытие кода уменьшится совсем немного.