Fixie – тестирование по соглашению

01Некоторое время назад попался мне твит о том, что знакомый стал использовать новый тестовый опенсорсный фреймворк Fixie и очень этим доволен. Так, что даже решил исправить все тесты в своем проекте на новый движок. После такого, я просто не мог оставаться в стороне и даже не взглянуть, что это за зверь такой и чем он так радует окружающих.

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

Как сказано на самом сайте, Fixie – Conventional Testing for .NET. Т.е. тестирование по соглашению. Под соглашениями здесь понимается то, к чему мы в целом привыкли – все операции выполняются на основе «устного» договора, джентельменского соглашения об именовании. Ближайший пример – scaffolding. Это когда мы договорились, например, что тестовые классы содержат слово Test, или что тестовые классы должны быть публичными и ничего не возвращать.  Тогда такие классы будут распознаны как тестовые. И больше никаких атрибутов и всего такого прочего. Просто классы и методы.

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

Установка и первый тест

По умолчанию, Fixie настроен так, что тестовыми классами является всё, что оканчивается на Tests. Тестовыми методами – всё что внутри этих классов и не возвращает значения. Т.е. теоретически и, на самом деле практически, вот такой код уже будет распознаваться как тест:

Подробнее

Бэкенд и «золотые молотки»

Привет, коллеги!

Мы анонсировали конференцию, посвященную Desktop UI & Business Application. В поддержку, чтобы посмотреть на настроения публики, была опубликована статья «WPF живее всех живых», которая оказалась дискуссионной и заставила нас в несколько другом свете взглянуть, на то, что и как мы хотим донести до широкой публики.

Как показали комментарии, не WPF единым живет десктоп разработка. Есть порты Qt для .NET, есть WinRT, если в эпсилон окрестности от дефолт-сити есть спецы по этим технологиям, которые хотят высказаться – у нас есть трибуна! Для этого все и задумано, чтобы показать различные варианты для ваших проектов.

Буквально вчера закончилась онлайн конференция dotNetConf 2015, которую, исходя из сообщений, Microsoft скорее возродила, нежели придумала заново. Конференция, судя по содержанию старается покрыть все основные области использования языка, это мультиплатформенность, веб, десктоп, доставка приложений, интеграция с Xamarin, будущее .NET, .NET Core, Roslyn Analyzer и другие темы. На мой взгляд, это генеральная репетиция перед конференцией //build, которая состоится в конце апреля-начале мая.

Подробнее

ReSharper и Roslyn: Q&A

Как уже все знают, MS предлагает «компилятор как сервис» в виде платформы Roslyn. Может быть некоторые из вас ее уже попробовали и составили какое-то первое мнение. После того, как почитаешь внимательнее возможности Roslyn и рассмотрев примеры работы с ним, возникает закономерный вопрос:

Как это будет работать с ReSharper и будет ли он переписан? Когда будет новый решарпер для новой студии?

В предыдущий раз ReSharper появился только в момент выпуска RC или около того, насколько я помню, т.е. достаточно поздно. Как оно будет в этот раз и как будут вместе жить ReSharper и Roslyn предлагается узнать из перевода интервью с разработчиками из JetBrains.

 

После анонса и выпуска Roslyn платформы на последней конференции BUILD, мы в JetBrains немедленно оказались погребены под вопросами о судьбе ReSharper, в смысле будет ли он использовать Roslyn для анализа кода и как они могут вместе сосуществовать. Поток вопросов не иссякнет, пока не будет использоваться единый шаблон для ответов на них:

resharper

Подробнее

Работа с MS Exchange — II

Составление строки поиска

Искать данные можно не только по одному полю, можно составлять весьма развесистые логические деревья для того, чтобы получить именно то, что надо.

В примере выше использован только один из вариантов. Сейчас я покажу как можно объединить условия поиска, общий алгоритм прост:

  • Создаем необходимые фильтры
  • Объединяем их в коллекции по логическому использованию «И» или «ИЛИ»
  • Создаем специальные коллекции для использования

 

Я думаю, что основная идея, как это работает, ясна. Так же советую поэкспериментировать с разными критериями поиска.

Подробнее

Работа с MS Exchange — I

сложность 100-200

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

Первые предположения сделали за меня, подумав, что надо будет соединятся с Outlook и через него выдирать сообщения и вложения к ним. К тому письму приложили до кучи пример, мол вот уже все готово, только оформите нам службу красивую. В примере конечно же использовались обертки над COM, с заголовками с структурами работы с С++. С этим языком я работал только в университете и как-то мне не улыбалось снова к нему обращаться, так как не умею на должном уровне. Помимо самой реализации, с которой возникли бы большие проблемы при желании как-то расширить пример, а такие желания возникают обязательно, была проблема безопасности Outlook, который спрашивал разрешения пользователя каждый раз, когда бы служба лезла к ящику. Кроме того реализация не учитывала новые клиенты и Office 2013 шел лесом. В общем, косяков слишком много, чтобы делать что-то серьезное таким способом.

Мир не мог быть так жесток и пришло спасение в виде EWS Managed API от самой MS. Полностью управляемый код для общения с сервером Exchange, что на мой взгляд гораздо лучше для работы с почтой, чем использовать API Outlook.

Кратно о возможностях библиотеки:

  • Возможность создавать, читать, манипулировать всеми пользовательскими элементами сервера (письма, контакты, календарные события, правила).
  • Не требуется пакет офис на целевой машине
  • Автоматический поиск сервера. Т.е. вы вводите только имя пользователя, пароль и имя ящика, все другие необходимые данные для связи библиотека постарается найти сама, в точности как Outlook.
  • NTLM и явная авторизация.

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

Что будет показано в статье?

Я планирую показать далее следующие техники:

  • Поиск писем и папок
  • Создание и отправка писем. С вложениями.
  • Удаление писем.
  • Ответ и форвардинг писем.
  • Получение писем, уведомления, извлечение вложений.

Подробнее

Создание проектов с NuGet и ReSharper

В этом видео я рассказываю как работать с пакетами NuGet, как их комплексно устанавливать. Как пользоваться ReSharper для добавления usings и почему я никогда не указываю используемые неймспейсы. Так же расскажу о некоторых подводных камнях.

 

Hard’n’Heavy!

 

 

Внедрение Notification Bar

Сложность 100

В прошлый раз я провел общий обзор компонента Notification Bar, рассказал как он работает, возможности, планы по развитию. Немного коснулся того, как модифицировать код, чтобы можно было внедрить Notification Bar (NB), насколько мало надо действий для этого. В этом посте я хочу детально разобрать о том, как внедрить систему уведомлений в приложение, и, я надеюсь, вы согласитесь с тем, что это сделать весьма просто.

Установка

Начнем с установки компонента. Это можно сделать с помощью NuGet пакета следующей командой:

Install-Package VioletTape.NotificationBar

При установке будут подгружены так же все зависимые компоненты и пакеты:

  • PostSharp Free Community Edition
  • PostSharp Threading Toolkit
  • PostSharp Domain Toolkit
  • Rx Framework
  • StructureMap
  • MakeMeAsync

Данный пакет необходимо будет установить для сборки с UI компонентами и для сборки с моделями.

UI настройка

Естественно, что для любой технологии и для любого компонента всегда есть некоторые ограничения и необходимые начальные условия. Так что предлагаю рассмотреть некоторые необходимые начальные условия для Notification Bar. На данный момент такими естественными ограничениями являются технологии:

  • .Net Framework 4.5
  • Windows Presentation Framework

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

Реализация данного интерфейса позволяет системе уведомлений переводить пользователей на нужные экраны и отслеживать текущее визуальное состояние программы. Я постарался максимально сократить требования интерфейса, чтобы максимально упростить внедрение.

В этом месте стоит остановится поподробнее и рассказать об общей системе приложений, о системе UI.

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

Подробнее

Notification Bar Overview

Сложность 100-200

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

Идея создания

Все идеи как всегда идут из жизни, из каких-то конкретных потребностей и фантазий на тему того как можно было бы их реализовать. В данном случае идея пришла из приложения, которое мы разрабатывали в рабочее время. Приложение являлось толстым клиентом для расчета/перевода внутренней бухгалтерии во внешнюю, и многие операции совершались достаточно долго. Долго это значит от 2 минут до 30 и более. Конечно же на это время приложение не зависало, было вполне отзывчивым, но отзывчивым фактически только для одного действия, отмены долгоработающего метода. Всякие визуальные игры в виде сортировки по колонком не берем за серьезный функционал.

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

Очень хотелось сделать так, чтобы можно было достаточно безболезненно модифицировать имеющийся код, чтобы можно было осуществлять свободную навигацию по приложению и видеть отчет о завершенном действии в области уведомлений приложения. Отчего-то хотелось именно в самом приложении обо всем сообщать, а не выносить в «иконку рядом с часами». Не буду лукавить, это «отчего-то» пришло от частого созерцания области уведомлений на планшете с Android 4, и мне очень нравится то, как сделаны уведомления в системе и хотелось их как-то повторить.

Получается, что есть два желания, которые коррелируют друг с другом очень хорошо, по крайней мере лучше, чем идеи в фильме Super 8. А так как идеи достаточно давно вынашивались и могла появится конкретная польза, то я решил реализовать всё не отдавая себя прокрастинации.

Итак, основная идея:

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

Все остальные вещи могут рассматриваться как дополнительные украшательства. Но по возможности стоит реализовать, если стоимость будет низка.

Подробнее

Notification Bar Overview Video

Сегодня я хочу для затравки показать функционал визуального компонента, который позволяет отображать внутрипрограммные уведомления в системном стиле. Причем для включения функционала не потребуется переработки моделей в общем случае. Но все подробности потом, а обзорное видео подкатом!

Notification Bar Overview

WPF Exception Viewer

Сложность 100-200

Достаточно давно я писал о том, как работать (обрабатывать) с исключениями при использовании класса Task из Task Parallel Library (TPL), все описанные способы действительно работают и проверены на практике уже много раз и отлично меня спасают и упорядочивают работу с потоками, особенно с получением исключений. Однако тогда я упустил важный момент как еще централизованно можно получать исключения и никак не был освещен вопрос удобства работы с исключениями: отображение и коммуникация от пользователя. Сегодня собираюсь наверстать упущенное тем более под руку подвернулся удобный и простой набросок от MarkLTX с CodeProject.

Как оно бывает обычно

Обычно отчет об ошибке выглядит примерно следующим образом:

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

Следующей проблемой является то, что сообщение об ошибке вываливается огромной простыней порой. Не так все страшно, когда это происходит у разработчиков, так как известно, что фокус стоит на кнопке «ОК», но пользователи этого не знаю и входят в ступор.

Так же пользователи не знаю, что текст можно копировать нажав Ctrl+C и высылают FullHD скриншот с ошибкой. Конечно весело порой посмотреть на чужие рабочие столы, но это быстро надоедает.

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

Подробнее