Показаны сообщения с ярлыком Visual Studio. Показать все сообщения
Показаны сообщения с ярлыком Visual Studio. Показать все сообщения

понедельник, 20 января 2014 г.

Microsoft Fakes. Тестирование поведения

DISCLAIMER: исходный код Verification Fakes можно найти на github, а скомпилированная версия доступна через nuget.org/packages/VerificationFakes.

В прошлой заметке мы рассмотрели примеры использования Microsoft Fakes для создания стабов – заглушек, возвращающих требуемые данные. Однако в некоторых случаях нам все же нужно проверить, что в определенных условиях тестируемый класс обращается к некоторой зависимости. Такой вид тестирования называется тестированием поведением и именно такой вид «подделок» каркасом Microsoft Fakes практически не поддерживается.

вторник, 14 января 2014 г.

Microsoft Fakes. Тестирование состояния

Все приведенные примеры можно найти на github.

Microsoft Fakes – это очередной изоляционный фреймворк, который является логическим продолжением экспериментального проекта Microsoft Moles.

Все изоляционные фреймворки делятся на несколько категорий, в зависимости от времени генерации «подделок» и их типу:

По времени генерации:

  • генерация на лету во время исполнения тестов;
  • во время компиляции;

По типу генерируемых «подделок»:

  • на основе полиморфизма, что позволяет «мокать» лишь полиморфные методы;
  • на основе CLR Profiling API, что позволяет мокать невиртуальные методы, включая статические.

среда, 14 марта 2012 г.

15 возможностей ReSharper-а для навигации и редактирования

Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше вы сможете сделать.
Энди Хант и Дейв Томас «Программист-прагматик. Путь от подмастерья к мастеру»

DISCLAIMER: это не заказная и совершенно не проплаченная статья (JetBrains, я ни на что не намекаюJ). Здесь представлены лишь возможности популярного расширения для Visual Studio (а иногда и аналогичные возможности самой студии), которые я лично использую в повседневной деятельности.

Инструменты не являются панацеей от кривых рук и сами по себе не сделают из заурядного специалиста аццкого сатану, способного рвать любую задачу, как известные четвероногий друг тряпку. Они не решают сами ваши задачи, а лишь помогают снять с плеч некоторые рутинные вещи и дают возможность сосредоточиться на главном, не задумываясь о таких мирских вещах, как добавление нужных директив using, проблемах форматирования или навигации по коду. Многие инструменты (в особенности ReSharper) могут помочь в решении и других, не мене важных задач, таких как поиск ошибок в коде, следование стандартам кодирования, запуск юнит-тестов и многих других. И хотя все эти возможности являются мегафичами сами по себе, но сегодня речь в основном пойдет о возможностях навигации и поиска.

Формат описания следующий: названия фичи, а затем в скобках горячие клавиши для схемы Visual Studio, а затем для схемы IDEA.

Например: Go To Type (Ctrl + T, Ctrl + N).

понедельник, 12 октября 2009 г.

[Visual C++ 2008] Duplicate cpp filename

Я все еще занимаюсь переводом старого С++ проекта с VS2003 на VS2008 и в процессе перевода столкнулся с одной интересной проблемой.

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

Проблема в том, что при компиляции файла с именем Foo.cpp студия генерирует объектный файл с именем Foo.obj, а если такой файл уже существует, то просто перезаписывает старый файл. В результате одного (или нескольких, в зависимости от количества cpp-файлов с одинаковыми именами) объектного файла будет не хватать, о чем любезно и сообщит линковщик.

Для проверки достаточно создать простое консольное приложение добавить Foo.h и Foo.cpp в корень и в подпапку, указать различные пространства имен и попробовать в Main.cpp создать объекты обоих классов.

Интересно то, что подобного поведения не было в предыдущих версиях компилятора и подобные проекты успешно компилировались как на VS2005, так и на VS2008. Там эта проблема решалась путем добавления в имя объектного файла чисел 2, 3 и т.д.

Еще более интересным является то, что эта проблема не будет решена до выхода очередной версии Visual C++. Вот один из ответов команды VC++ Team, найденный на MSConnect:

“Unfortunately we will not be able to fix this issue during this release. Please feel free to reactivate the bug if this is a blocking scenario.

Having duplicate file names in the same project is not a supported scenario. As a workaround as you recognize please change the name of the files that are being included in the same project.”

Подробности можно найти здесь и здесь.

Существует по крайней мере два обходных пути (возможны и другие, о которых я не знаю):

1. Избавиться от неуникальных файлов путем переименования.

2. Явно задавая имя объектного файла в свойствах конкретного файла.

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

Update (2009-10-14)

Существует по крайней мере один более изящный способ решения этой проблемы: можно для группы файлов, чьи имена совпадают с другими cpp-файлами в свойствах изменить поле Object File Name с $(IntDir)\ на $(IntDir)\Your Sub Dir\, в результате чего, объектные файлы для этих cpp-файлов будут складываться в указанную подпапку.

вторник, 6 октября 2009 г.

[Visual Studio] Find & Replace

В данный момент я работаю над переводом одного старого проекта, написанного под .Net Framework 1.1 на .Net Framework 3.5. При этом одной из задач является переход с синтаксиса Managed C++, на синтаксис C++/CLI.

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

Итак, задача: переделать свойства с синтаксиса Managed C++ в синтаксис C++/CLI.

Синтаксис свойства на Managed C++:
__property int get_EventType() { return eventType_; }

Синтаксис свойства на С++/CLI:

property int EventType { int get() { return eventType_; } }

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

Шаблон для поиска:

__property:b+{.#}:b*\*@:bget_{:w}\(\):b*(\n*:b*)\{\n*:b*{.*;}:b*\n*:b*\}

Шаблон для замены:

property \1 \2 { \1 get() { \3 } }

Синтаксис регулярных выражений в Visual Studio несколько отличается от общепринятого, но это не слишком важно, т.к. идея остается той же и в msdn прекрасно описаны особенности.

Теперь, запустив в Visual Studio механизм Find & Replace мы будем заменять свойства вида:

__property int get_EventType() { return eventType_;  }

Или

__property int get_EventType()

{

    return eventType;

}

На свойства вида:

property int EventType { int get() { return eventType; } }

Как правильно писал Джон Роббинс, разработчики очень часто плохо отзываются о своих пользователях, поскольку те не читают документацию и слабо используют функционал их приложений, но сами разработчики в этом плане не так уж и далеки от своих пользователей, когда речь касается об использовании функционала среды разработки.  Visual Studio содержит множество функций и инструментов, способных существенно упростить жизнь каждому разработчику, но мало кто из них (из нас) считает нужным изучать подобные возможности. Функция Find & Replace не является исключением. Представленный шаблон для преобразования синтаксиса свойств не претендует  на полноту, он подходит под тот формат записи, который применяется у меня, но возможно потребует некоторых изменений для вас. Но я и не хотел сделать инструмент, подходящий на все случаи жизни, а, скорее, продемонстрировать возможности инструмента, который всегда рядом и вполне может помочь для решения повседневных задач кодирования.