Недавно была выпущена первая бета версия тестового фреймворка NUnit v3. Кроме всего прочего, эта версия реализует параллельное выполнение тестов (практически «из коробки»). Я решил проверить как это работает на одном реальном проекте и обнаружил, что новая версия nunit-а не поддерживает часть используемых вещей предыдущих версий. В частности предлагается вместо аттрибута ExpectedException использовать Assert.Thorws или Assert.That.
Независимо от релиза этой беты, в одном из проектов начал использовать модель Assert.That вместо всех остальных методов и атрибутов nunit-а.

Под катом небольшой опыт перевода аттрибута ExpectedException в модель Assert.That.

Как известно, недавно была выпущена 9 версия решарпера, которая поддерживает

many C# 6.0 features such as static usings and the?.. operator

Тем, кто устанавливает решарпер и собирается им пользоваться в VS2015 Preview надо иметь ввиду какие фичи не поддерживаются.

Довольно давно я делился проблемой тестирования кода в финализаторе и недавно жаловался на падение теста (Как тестировать код финализатора (c#) и Как тестировать код финализатора (c#). Послесловие: тест все-таки упал).
В ходе обсуждения комрадом withkittens была высказана идея:

Финализатор (при правильной реализации IDisposable pattern) должен (should) вызывать Dispose(false). Этот факт можно тестировать статическим анализом. Соответственно, если Dispose(false) вызывает удаление файла (вы же написали тест?), то можно быть уверенным, что и финализатор тоже вызовет удаление файла, unit-тест излишен.

Мне эта идея показалась очень здравой, кроме того, иногда хочется контролировать исходный код более кастомно, чем дает встроенный анализ кода или решарпер.
Опыт реализации кастомных правил анализа кода под катом + «как ozcode помог в процессе исследования внешней библиотеки»

Уже довольно давно я опубликовал пост «Как тестировать код финализатора (c#)», в котором делился опытом тестирования кода, реализованного в финализаторе. Не прошло и года, как тест все-таки упал. Подробности под катом.

Введение.

Продолжаю удивляться делиться опытом перехода из SVN на TFS (или как правильно подметили Team Foundation Version Control (TFVC)).
В предыдущем посте был описан опыт чисто системы управления версиями.
В этом посте я хотел бы поделиться маленьким (но важным) сценарием использования интеграции системы «контроля версиями» с системой «управления дефектами» (или как это называется Work Item Tracking).

Введение.

Не так давно один из проектов, в котором я участвую, перевели из SVN на TFS. Этот проект (десятки тысяч файлов, включая двоичные файлы) много лет жил и развивался под SVN. Поработав несколько месяцев после перехода, появился некий опыт, которым хочется поделиться.
Важно понять, что это опыт человека после SVN. Я использовал TortoiseSVN (плагин для Windows Explorer) и AnkhSvn — для Студии.

мои впечатления под катом

После проверки того, что можно как то делать навигацию в студии и без решарпера, решил исследовать следующий важный для меня сценарий: а именно unit тестирование в студии (с использованием тестового фреймворка nunit).

Давно пользуюсь таким замечательным продуктом как Resharper. Пользовался бы и дальше, если бы не щедрость Microsoft и странное поведение продавца от JetBrains.
Таким образом есть студия 2013 и заканчивается пробная лицензия от Resharper-8. Решил попробовать, можно ли жить в студии (для начала Ultimate редакции) без решарпера. Кроме того, как не удивительно, некая часть разработчиков пользуются только не большим набором возможностей решарпера. Нельзя ли их перевести на встроенные фичи или бесплатные инструменты, что бы бухгалтерию зря не напрягать.
Исследование вопроса под катом.

Одной из не очевидных задач, является тестирование кода, реализованного в финализаторе дотнетовского класса.
Данная заметка рассматривает один из способов решения этой задачи.

По следам поста Визуализация списков в отладчике Visual Studio или новое слово от «BugAid For Visual Studio», что бы чисто добить тему, хотелось бы рассмотреть возможности расширения BugAid для визуализации вычисления выражения в операторе if.

Когда приходится просматривать элементы списка (массива) в отладчике Visual Studio, например, в окне QuickWatch часто сталкивашься с не удобством просмотра сложного (или длинного) списка данных. Тяжело увидеть, например, значения поля всех элементов списка.
Данный пост показывает несколько «встроенных» способов решения этой проблемы и возможности расширения BugAid.
мало букв, но достаточно картинок.

Доброго времени,

Как известно, Resharper решает много проблем по работе с кодом, но все-таки не все.

Одной из такой, не очень решенной, проблемой является навигация по зарегистрированным в IoC контайнерах классам.

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