Вопросы по началу работы для NUnit (или NUnitLite) и .NET CF - PullRequest
Новая
       21

Вопросы по началу работы для NUnit (или NUnitLite) и .NET CF

4 голосов
/ 28 февраля 2009

У меня есть существующее приложение VS 2005 Std .NET Compact Framework, для которого я хочу провести несколько основных рефакторингов. В настоящее время нет модульного тестирования, но я хочу добавить это, прежде чем связываться с кодом. У меня нет практического опыта в модульном тестировании, хотя я знаю теорию (просто никогда не удосужился ее реализовать; я знаю: позор мне :-)) Вот несколько вопросов, над которыми я сейчас размышляю:

a) Как новичку, я должен использовать NUnit или NUnitLite (который, как утверждается, проще в использовании)?

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

в) Как класс, который я хочу протестировать, обычно включается в тестовый проект? Мое приложение представляет собой файл .EXE, то есть я не могу просто ссылаться на него как сборку .DLL из тестового проекта (или я могу? Никогда не пробовал это ...). Я проверил различные учебные пособия по NUnit, но либо не нашел упоминаний об этом, либо один учебник предложил скопировать и вставить класс, который я хочу протестировать, в тестовый проект (yuk!). Должен ли я ссылаться на исходный файл исходного кода в моем тестовом проекте? А как насчет частных методов или зависимостей от других классов?

d) Должен ли я начать изменять свой исходный код, чтобы обеспечить лучшую тестируемость, например сделать частные методы общедоступными, развязать и т. д.? Это немного похоже на рефакторинг перед тестированием, что не очень хорошо для меня ... Или лучше вообще не трогать исходный код в начале, даже если это означает меньшее покрытие кода и т. Д.? 1009 *

e) Стоит ли искать другие инструменты или дополнения, которые использует большинство людей?

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

Ответы [ 2 ]

7 голосов
/ 28 февраля 2009

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

Он познакомит вас с NUnit, но, что более важно, автор предоставит вам множество советов, как писать хорошие модульные тесты в целом. Тестовые среды xUnit не очень сложны, и вы очень быстро привыкнете к их API / рабочему процессу. Сложным является фактический процесс определения граничных условий, уменьшения связи и проектирования для проверки. Он доступен в виде электронной книги (PDF) или печатной копии.

Относительно ваших актуальных вопросов (книга также даст вам несколько ответов):

  • @ a) У меня нет опыта работы с NUnit lite, поэтому я не могу дать вам совета по этому вопросу.
  • @ b) Модульные тесты должны быть очень локальными с точки зрения их зависимостей. Вы стремитесь протестировать классы, независимые друг от друга, поэтому не нужно было бы сначала развертывать их на мобильном устройстве. Вы не будете запускать полное приложение, просто тестируйте компоненты изолированно. Следовательно, я бы рекомендовал использовать ваш настольный компьютер в качестве цели для вашей среды модульного тестирования. Вы также получите лучшее время оборота.
  • @ c) Вы должны ссылаться на сборку, которая содержит классы, которые вы хотите протестировать в своем тестовом проекте. Тестовый проект будет самой сборкой (DLL). Тестовый прогон выполняет эту сборку и использует хранимую метаинформацию для запуска содержащихся тестов.
  • @ d) Это во многом зависит от состояния и дизайна вашего программного обеспечения. Но в целом я бы использовал стратегию «разделяй и властвуй»: вводите интерфейсы между классами и начинайте поэтапный рефакторинг. Напишите модульные тесты, прежде чем начинать менять реализацию. Интерфейсы поддерживают контракты в рабочем состоянии, но при необходимости вы можете изменить базовую реализацию. Не делайте частные методы публичными, чтобы сделать их тестируемыми. Приватные методы - это внутренние помощники класса, которые поддерживают публичные методы при выполнении своей работы. Поскольку вы тестируете свои публичные методы, вы утверждаете, что ваши приватные методы делают правильные вещи.
  • @ e) Полезным дополнением для Visual Studio является TestDriven.Net . Это позволяет вам запускать тесты NUnit непосредственно из IDE, не переходя на графический интерфейс NUnit или консольный запуск.
2 голосов
/ 28 февраля 2009

@ c) Я не пробовал, но я думаю, что VisualStudio позволит вам добавить ссылку на проект из вашей тестовой сборки в вашу реальную сборку кода, даже если это exe.

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

Я все же тестирую публику и внутренности. Одна вещь, которую я считаю очень полезной, это атрибут InternalsVisibleTo : 

[assembly:InternalsVisibleTo("MyTestAssembly")]

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

...