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

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

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

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

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

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

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

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


unit-testing nunit compact-framework
person Timo    schedule 28.02.2009    source источник

Ответы (2)


arrow_upward
7
arrow_downward

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

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

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

  • @a) У меня нет опыта работы с NUnit lite, поэтому я не могу дать вам совет по этому вопросу.
  • @b) Модульные тесты должны быть очень локальными в отношении их зависимостей. Вы стремитесь тестировать классы независимо друг от друга, поэтому нет необходимости сначала развертывать их на мобильном устройстве. Вы не будете запускать полное приложение, а только будете тестировать отдельные компоненты. Следовательно, я бы рекомендовал использовать ваш настольный компьютер в качестве цели для вашей среды модульного тестирования. Вы также улучшите время оборота.
  • @c) Вы должны сослаться на сборку, содержащую классы, которые вы хотите протестировать в своем тестовом проекте. Тестовым проектом будет сама сборка (DLL). Средство выполнения тестов выполняет эту сборку и использует сохраненную метаинформацию для запуска содержащихся в ней тестовых случаев.
  • @d) Это во многом зависит от состояния и дизайна вашего программного обеспечения. Но в целом я бы использовал стратегию «разделяй и властвуй»: вводить интерфейсы между классами и начинать рефакторинг шаг за шагом. Пишите модульные тесты до того, как начнете менять реализацию. Интерфейсы поддерживают работоспособность контрактов, но при необходимости можно изменить базовую реализацию. Не делайте частные методы общедоступными только для того, чтобы их можно было проверить. Частные методы — это внутренние помощники класса, которые поддерживают общедоступные методы при выполнении своей работы. Поскольку вы тестируете свои общедоступные методы, вы будете утверждать, что ваши частные методы работают правильно.
  • @e) Полезным дополнением для Visual Studio является TestDriven.Net. Он позволяет запускать тесты NUnit непосредственно из IDE, не переходя на графический интерфейс NUnit или средство запуска консоли.
person olli-MSFT    schedule 28.02.2009
comment
+1 отличная книга. Купил по совету кого-то из SO и ничуть об этом не пожалел (в частности, весь прагматичный стартовый набор) - person Steven Evers; 01.03.2009

arrow_upward
2
arrow_downward

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

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

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

[assembly:InternalsVisibleTo("MyTestAssembly")]

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

person CodingWithSpike    schedule 28.02.2009