NUnit против ручного юнит-тестирования - PullRequest
2 голосов
/ 02 октября 2011

Справочная информация

Недавно я пытался разработать набор тестов для регрессионного тестирования конкретного приложения.Я использовал NUnit и у меня не было проблем.

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

Вопрос

Допустим, я реализую простой тестер модулей, который загружает класс, запускает методы Startup, Test и Teardown по порядку, перехватывает исключения и затем выгружает сборку.Каковы недостатки этого по сравнению с использованием NUnit?

В этом сценарии я могу легко передавать параметры в мои тестовые случаи или делать любые другие сумасшедшие вещи, которые я могу придумать.Но меня беспокоит то, что я теряю от отказа от NUnit.

Ответы [ 2 ]

6 голосов
/ 02 октября 2011

Что вы теряете?Ваше время.

Если вы работаете на клиента или бизнес, они (предположительно) платят вам за решение бизнес-задач, а не за написание кода инфраструктуры.Некоторая инфраструктура может быть необходима для удовлетворения потребностей бизнеса.В этом случае это явно не так.Вы заново изобретаете колесо.

Не попадайтесь в ловушку Не изобретено здесь.Используйте NUnit.Он поддерживает параметризованные тесты .Если NUnit не отвечает вашим потребностям, изучите MbUnit или xUnit.net .Или посмотрите на SpecFlow и т. Д. Для BDD-стиля.Или FitNesse для приемочных испытаний.И это только частичный список!

Если вы пишете тестовый фреймворк самостоятельно для целей обучения, отлично!Если нет, вы тратите свое время и / или деньги своей компании.

Решение технических вопросов

JUnit был изначально создан во время длительной поездки на самолете .Тогда не было много альтернатив.Написание среды тестирования не является огромным проектом.Написание надежного, полнофункционального и простого в использовании сложнее.Написание тестов, интеграция IDE, интеграция CI, интеграция покрытия кода и т. Д. Значительно сложнее.И это было сделано .Если вы не Ayende Rahien, не делайте этого!

В дополнение к интеграции, вы также потеряете все функции NUnit , которые вы не реализуете (и их много),Я не использую все это, но я полагаюсь на многие из них.

(Удалено из моих комментариев)

0 голосов
/ 06 декабря 2018

Две части, в основном независимые части в этом вопросе:

  • Каковы плюсы / минусы создания нашей собственной реализации
  • Почему этот вариант использования не дает оснований даже играть сИдея создания собственной реализации

1) Поскольку это относится к «переизобретению колеса», все плюсы и минусы идентичны и являются более общими, чем этот вопрос, и все эти рассуждения применимы кэтот случай.

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

(в 1990-х годах я встретил парня, который писал свою RDBMS, потому что ни Oracle Database, ни SQL Server6.5 «не был способен» делать то, что он хотел ... кстати, это был перелистываемый курсор)

2) Отправка параметров в тесты NUnit аналогична любой другой задаче конфигурации / настройки параметров.Вы можете прочитать ваши конфиг / параметры из выбранного вами формата (скажем: XML, json, RDBMS) и сделать это как в настройках, так и в разборке и в «тестовых» методах.

Вы можете создать

  • a) полностью настраиваемую реализацию (я имею в виду чтение вашей конфигурации в настройке, тестировании и демонтаже)
  • b) или вы можете положиться на[TestCaseSource] или некоторый связанный атрибут
  • c) или extension NUnit
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...