Система юнит тестов - логический компилятор вашего приложения

"A unit test is almost always written using a unit-testing framework" Roy Osherove, The Art of Unit Testing.

Всем привет.

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

Тему эту я решил поднять поскольку был на тренинге "TDD в .NET". Тренинг прошел круто, полезно и об этом можно почитать уже в нескольких отчетах. Просто спросите гугл: TDD в .NET на XPDays и он вам все расскажет.

Но что я вынес для себя и почему выбрал именно такой заголовок статьи, а не другой?
За свои скромные несколько лет работы я вынес одну банальную вещь - программисты народ ленивый, менеджерам всегда не хватает времени, поэтому хватит экспериментов, делайте как работает и не ерзайте. Соответственно, если вы хотите ввести какую-то полезную практику у себя на проекте, то в первую очередь позабодтесь об удобных инструментах для работы. Будь-то ревью кода, continuos integration, continous delivery.

Так вот возвращаясь к теме TDD. До тренинга я думал, что писать тесты до кода это сложно, непонятно, скучно. Но как оказалось наука ушла далеко вперед. Наши тренеры (Александр Белецкий @alexbeletsky и Сергей Калинетц @skalinets) показали нам связку из плагинов для студии и фреймворков для юнит тестов, которые делают разработку тестов удобной, быстрой, а их проверку и запуск настолько нативной, насколько для меня уже стала перекомпиляция проекта. Вам не нужно даже сохранять файлы с вашими изменениями в тестах и логике, для того чтобы видеть ошибки и проваленные тесты.
Потом, вечерком переваривая всю полученную информацию я и подумал о наборе юнит тестов, как об еще одном уровне компилятора - компиляторе вашей логики, который работает в фоновом режиме и сразу же проверяет насколько были правильными ваши изменения.

Инструменты следующие, очень советую посмотреть всем кто пишет на C#:

• xUnit (NUnit) - фреймворки для юнит тестов
• NSubstitude - фреймворм для создания моков(заглушек, пустышек для тестов)
• Test Driven.NET - плагин, который позволяет запускать тесты под разными тулзами, и под дебагом в том числе
• NCrunch - плагин, который в фоне запускает тесты и выдает вам красивый результат в картинках, визуально показывает покрыт ли ваш код тестами

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

Также отдельно постараюсь написать о тестах и инструментах в С++. Все-таки это мой родной язык и жаль, что ситуация там немного хуже. Очень буду рад пообщаться на тему реального, практического использования TDD и юнит тестов в С++. Какие инструменты вы применяли и как настроили воркфлоу?

Всем доброй ночи. 

Command Window and Macros in Visual Studio. Part 2

Всем привет.

В прошлой статье я рассматривал работу с командной строкой в Microsoft Visual Studio. Сегодня мы продолжаем ковырять студию и рассмотрим работу с макросами в студии. Одним из самых мощных инструментов для автоматизации работы.

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

У нас на проекте для сборки игры используется Nant. Тем кто не знаком с этой системой советую ознакомиться. А пока небольшая вводная. Nant  это система, которая позволяет выполнять из командной строки различные команды. Реализован он на С# и доступен вместе с исходниками. Но основным достоинством Nant является широкий набор команд, а также возможность писать свои собственные команды на любом скриптовом или компилируемом языке, главное чтобы этот скрипт или скомпилированное приложение можно было выполнить из командной строки. 

У нас на проекте с помощью Nant собирается все, начиная от артовых ресурсов и заканчивая исходным кодом. Соответственно есть команды BuildGameCode, BuildGameAnimation, BuildLevel  и т.д.

Для конфигурации команд используется конфигурационный xml файл. 

Единственное неудобство, что пишу код я в студии, а вот для запуска команд приходиться использовать что под руки попадется. Одно время запускал просто из виндовой командной строки, потом использовал Luancher, потом использовал Notepad++. Правда в последнем случае кодировать тоже приходилось в блокноте, что не всегда удобно. 

Вот после всех скитаний попробовал использовать макросы в Visual Studio и получилось достаточно неплохо.

Использование макросов имеет несколько неоспоримых плюсов:

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

Но как всегда есть и несколько минусов:

• писать макросы можно только на Visual Basic .Net
• макросы это единичные команды - они хороши когда нужно выполнить быстрое, конечное действие, но когда вам нужно, что постоянно выполнялся некий процесс в фоне, то лучше использовать плагины

И еще один момент, который я пока не могу занести в минусы - это создание диалоговых окон. Предположим вы хотите, чтобы при вызове вашей команды открылось диалоговое окно (которое вы предварительно задизайнили) потом вы ввели некие значения в поля окна и нажав клавишу "Enter" получили результат. Так вот я не знаю, можно ли создавать свои окна, не успел проверить. 

Вернемся к моему примеру. Итак я создал макрос, который позволяет запустить любую команду или набор команд из командной строки в студии. Лог при этом выводится в это же командное окно, что позволяет мне его потом легко проанализировать и сохранить в файл. Также я написал команду, которая позволяет поменять любое поле xml файла конфигурации, например имя уровня с которого нужно стартовать. 

Следующая возможность, которую я хотел получить от макросов, это возможность снипетты, которых нет в студии ни для С++, ни для Lua. 

С макросами этот момент также оказался достаточно простым. Я создал текстовый файл, некий шаблон, в котором есть специальные символы $1, $2 и т.д. При вызове команды, текст из файла вставляется в код и символы заменяются параметрами, которые были переданы в команду. Вот и у нас есть снипеты. 

Всем доброй ночи. 

Command Window and Macros in Visual Studio. Part 1

Последнее время приходиться писать на Lua, а также постоянно работать с командной строкой.
Лучшим вариантом для редактирования Lua является блокнот Notepad++. Во всяком случае я пока ничего лучше не нашел. Бесплатная лицензия, наличие широкого выбора плагинов, хорошая скорость работы делают его очень привлекательным вариантом. 
Но не хочется переключатся в блокнот, студия ближе, да по ходу работу иногда приходиться править С++ код, искать различную информацию в С++ коде. А в данном моменте студия пока обходит блокнот.

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

Вариант первый - плагин.
Это самый первый вариант, который приходит в голову, особенно когда спишь и видишь славу Visual Assist-а и ReSharper-а. Сразу тянет создать свой аналогичный плагин только под Lua. 
Создал и сел думать, а какой же функционал туда забить. Не придумал, вернее его было так много, что на десяток плагинов хватит. А вот первой ключевой фичи, которая которая потянет за собой остальные я не нашел. Потом я нашел еще несколько причин не использовать плагин:

• неясен функционал

 

• относительно долгий цикл добавления фичей - нужно скомпилировать плагин, перезагрузить его в студии.

 

• необходимость думать о визуальном интерфейсе

 

И тогда я наконец понял, что мне нужно. 

Вариант второй - СКРИПТ.
Но не просто скрипт, а скрипт, который может взаимодействовать со студией, править файлы проекта, получать информацию о классах и т.д.
В качестве отправной точки поисков я выбрал CommandWindow. Здесь меня ждал сюрприз. 
CommandWindow позволяет делать все, вызвать любую команду, которая есть в студии. 

При наборе команды появляется окно подсказка с вариантами команд

Например команда File.OpenFile
Синтаксис следующий "File.OpenFile filename". Причем при наборе имени файла студия тут предлагает варианты, не хуже чем это делают Visual Assist и ReSharper.

Также есть еще одна дополнительная возможность: присвоение команде короткого имени. Это избавляет от необходимости писать длинную команду. Вот вариант короткой команды File.OpenFile

Команда для создания синонима команды называется Tools.Alias или просто alias. Если просто вызвать alias, то можно посмотреть список уже заданных сокращений
Кроме того она позволяет создать синоним для команды с определенным набором параметров. Например после вызова "alias openSealedFile File.OpenFile SealedClass.h" я смогу использовать openSealedFile для открытия файла SealedClass.h

И на закуску еще один бонус - CommandWindow работает в Visual Studio Express Edition

Все это хорошо, но не хватает еще одной вещи - собственно самих скриптов.
И об этом я расскажу завтра
А на сегодня еще один вопрос в качестве домашнего задания: какие еще интересные возможности Visual Studio вы знаете и используете?

Всем доброй ночи.