Введение в модульное тестирование для c# проектов в среде MonoDevelop

[Arei]

Продолжение будет?

[true_night]

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

[kekekeks]

Самое неприятное, что в MonoDevelop оснастка для Unit-тестирования гвоздями приколочена к NUnit и по сути является всего лишь интерфейсом к нему. Какое-либо API, позволяющее использовать иные системы просто напросто отсутствует. В результате интеграция того же xUnit, являющегося существенно более продвинутым, видится делом весьма трудозатратным.
Это крайне печалит, ибо NUnit все тесты из конкретного кейса выполняет используя один и тот же экземпляр класса, в результате, если не позаботиться о том, чтобы в начале работы каждого из них было «чистое» состояние, то можно получить несколько странные результаты.

[build_your_web]

Самое неприятное, что в MonoDevelop нет Resharper'a.

[kekekeks]

Ну они тащат из него часть фич, хотя это больше заслуга NRefactory.

[true_night]

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

[x2bool]

Mike Kruger в твиттере отмечал необходимость XUnit addin'a. Так же он сказал, что было бы не плохо, если комьюнити поможет реализовать поддержку XUnit.

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

А насчет одного экземпляра на множество кейсов — разве не должно быть так? По-моему, NUnit так и работает? XUnit, да, этот точно создает по экземпляру на тест.

[kekekeks]

А насчет одного экземпляра на множество кейсов — разве не должно быть так? По-моему, NUnit так и работает? XUnit, да, этот точно создает по экземпляру на тест.

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

Относительно единого AddIn-а: что у NUnit, что у xUnit есть режимы работы для TeamCity, обеспечивающие некоторый унифицированный вывод на stdout. Вполне возможно, что имеет смысл использовать консольные runner-ы и сделать унифицированный GUI с нуля.

[x2bool]

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

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

[kekekeks]

Убиение процесса является вполне корректным способом остановки, особенно если какой-то тест банально ушёл в бесконечный цикл.