Как стать автором
Обновить

Комментарии 10

Продолжение будет?
Если вы желаете, что-нибудь спросить, то спрашивайте, не стесняйтесь. Если потребуется дать довольно емкий ответ, то конечно будет написано продолжение.
Самое неприятное, что в MonoDevelop оснастка для Unit-тестирования гвоздями приколочена к NUnit и по сути является всего лишь интерфейсом к нему. Какое-либо API, позволяющее использовать иные системы просто напросто отсутствует. В результате интеграция того же xUnit, являющегося существенно более продвинутым, видится делом весьма трудозатратным.
Это крайне печалит, ибо NUnit все тесты из конкретного кейса выполняет используя один и тот же экземпляр класса, в результате, если не позаботиться о том, чтобы в начале работы каждого из них было «чистое» состояние, то можно получить несколько странные результаты.
Самое неприятное, что в MonoDevelop нет Resharper'a.
Ну они тащат из него часть фич, хотя это больше заслуга NRefactory.
Абсолютно с вами согласен. Если не следить за созданием новых объектов, то можно случайно обнаружить нежелательно созданные объекты и подобные вещи.
Mike Kruger в твиттере отмечал необходимость XUnit addin'a. Так же он сказал, что было бы не плохо, если комьюнити поможет реализовать поддержку XUnit.

Я даже проводил небольшое исследование по MD, XUnit, NUnit фреймворкам. Задача не тревиальная. А текущий NUnit addin действительно тихий ужас. Только немножко разобрать и прокомментировать код этого дополнения стоило мне много времени.

А насчет одного экземпляра на множество кейсов — разве не должно быть так? По-моему, NUnit так и работает? XUnit, да, этот точно создает по экземпляру на тест.
А насчет одного экземпляра на множество кейсов — разве не должно быть так? По-моему, NUnit так и работает? XUnit, да, этот точно создает по экземпляру на тест.
Да, NUnit так и работает, что вызывает ряд проблем. Например, у вас во всех тестах используется общий код инициализации, который достаточно «толст», чтобы его вынести в конструктор и занести нужные данные в поля класса. Если тест меняет состояние объектов, то данный подход становится неприменим в случае одного экземпляра на все тесты.

Относительно единого AddIn-а: что у NUnit, что у xUnit есть режимы работы для TeamCity, обеспечивающие некоторый унифицированный вывод на stdout. Вполне возможно, что имеет смысл использовать консольные runner-ы и сделать унифицированный GUI с нуля.
Поигрался с консольным runner-ом. Есть загвоздка: непонятно как остановить выполнение (например, по требованию пользователя). Можно, конечно, делать Process.Kill() для Runner-a. Только будет ли это корректным, на середине выполнения теста убивать процесс? Еще один недостаток: результат выполнения будет для всех тестов разом (т. е. синхронно подсветить результат красным или зеленым не получится).

Есть вариант создать своими силами простенькое консольное приложение. В нем реализовать IRunnerLogger и по мере выполнения тестов выводить на stdout результат «строка за строкой», а в Addin-e синхронно парсить вывод. Однако, не могу придумать, как корректно остановить выполнение.
Убиение процесса является вполне корректным способом остановки, особенно если какой-то тест банально ушёл в бесконечный цикл.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории