Где вы размещаете модульные тесты для частных методов?

Question

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

article in Wikipedia предлагает:

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

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

Любые мысли по этому поводу?

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

Answer 1

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

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

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

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

Answer 2

Ваше название вопроса и первое предложение разные. :)

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

Answer 3

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

посмотреть этот блог: testing private methods

Answer 4

Do не модульного тестирования частные методы. Модульные тесты предназначены для тестирования видимого (так общедоступного и защищенного) интерфейса класса. Частные методы - это детали реализации, и для них не требуется выполнять единичные тесты (их поведение должно быть неявным образом проверено на тестах на видимые методы), приводит к хрупким испытаниям (поскольку детали реализации могут меняться) и является препятствием для рефакторинга.

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

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

Нигде не было. Их не существует.

В целом, мои модульные тесты находятся в отдельных проектах.

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

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

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

Answer 8

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

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

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

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

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