Team Foundation Server 2012. Настройка workflow Build-Deploy-Test для стандартного окружения.

Хочу поделиться со всеми моим опытом использования Team Foundation Server 2012 (здесь я рассказывала про версию 2010) и Lab Management для настройки workflow Build-Deploy-Test для стандартного окружения.

Настройка workflow Build-Deploy-Test для стандартного окружения.

Использование Specflow для автоматизации тестов на русском языке

Всем привет! Сегодня меня 2 раза спросили про Specflow. Затем я увидела пост на хабре про Specflow. И поняла - вот он тот драгоценный момент, чтобы поделиться с вами записью моего выступления на автоконфетке осенью 2012 года, где я рассказывала про использование Specflow в автоматизации тестирования. Другого шанса судьба мне может не дать =))
Ловите презенташку и видео.

Рефакторинг. Предварительные приемы.

   Наверняка многие из нас, особенно те, кто пишет программный код,  слышали о рефакторинге. Хочу поделиться с вами предварительными приемами рефакторинга, взятыми из замечательной книжки - "Рафакторинг в C# и Asp.Net для профессионалов", Даниэль Арсеновски. Отличная книга, в ней все разложено по полочкам с объяснениями на практических примерах, всем советую.
   Для начала, определение.

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

    Рефакторинг состоит из трех шагов:
1. Идентификация кода с душком.
2. Применение подходящего рефакторинга.
3. Выполенение unit-тестов.

   Предварительные приемы рефакторинга обычно выполняются на уровне синтаксиса. К ним относятся следующие:
1. Исключение мертвого кода.
Он может быть в виде закомментированных участков кода, игнорируемых параметров и возвращаемых значений методов, неиспользуемых методов и т.д.. Такой мертвый код вносит путаницу и дополнительную сложность и должен быть удален.

2. Сокращение области видимости и уровня доступа излишне открытых элементов.
Открытие ненужных внутренних деталей противоречит принципу хорошо инкапсулированного кода - принципу сокрытия информации/реализации.

3. Использование явного импорта.
При чтении кода вы полагаетесь на раздел импорта, чтобы выявить зависимости, присутствующие в коде. Использование полностью уточненных имен вместо раздела импорта может значительно затруднить понимание зависимостей в коде. Поэтому предпочтение стоит отдавать явному импорту.
Пример:
вместо
  System.Xml.XmlDocument doc = new System.Xml.XmlDocument();
использовать
  using System.Xml;
  ......
  XmlDocument doc = new XmlDocument();

4. Удаление неиспользуемых ссылок на сборки.
Неиспользуемые ссылки - это почва для излишних зависимостей. Эта зависимость говорит разработчикам, что они могут использовать службы, предоставленные ссылаемой сборкой. Если ссылка не будет удалена из проекта, то в какой-то момент в будущем она будет использована вновь. Такой путаницы нужно избегать.

Coded UI Test. Работа с глубоко вложенными контролами в WPF.

        Хочу поделиться с вами ссылкой о том, как тестировать окно WPF-приложения в случае, когда присутствует глубокая иерархия контролов. Мне эта статья в свое время очень помогла. Благодаря ей получается красивая UIMap окна, соответствующая реальной структуре его контролов.
       Всех с наступающими праздниками :)

Coded UI Test. Увеличение скорости работы с контролами.

      В одной из статей своего блога я писала про то, как увеличить работу с текстовым полем. И хотя определенное решение было найдено, меня не оставлял в покое вопрос, почему же в текстовое поле так долго вводится текст. Даже бесплатный фреймворк White вводит текст очень быстро. А тут платный, крутой Coded UI, от самих Microsoft, чьей преданной поклонницей я являюсь)) Я гуглила не один раз, и в различных блогах натыкалась на такие же жалобы и различные варианты решения этой проблемы.
     И все-таки решение нашлось. А всего-то надо было внимательнее читать msdn. Еще раз убедилась, что там можно найти практически все, что  надо для успешной работы. Все оказалось так просто и очевидно, что я удивилась, как это решение не нашлось раньше.
    В CodedUI есть специальный класс Playback, который отвечает за различные настройки проигрывателя ваших тестов. Все, что требуется, это установить одно его свойство:

          Playback.PlaybackSettings.WaitForReadyTimeout = 100;

где 100 - это количество мс, тут уже играйтесь с настройками так, как вам нужно.

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

Расширения для Coded UI Test

     Данная статья будет полезна тем, кто разрабатывает C# тесты для автоматизации UI приложения. При разработке тестов часто бывает так, что средств, предоставляемых выбранным фреймворком для тестирования (в нашем случае UI) недостаточно для решения конкретной задачи, и приходится подпиливать его под свои нужды. Раньше я уже описывала несколько способов решения таких проблем касательно Coded UI. Хочу рассказать еще об одном, самом универсальном способе - создании методов расширения для работы с контролами.
     Рассмотрим самый простой пример.
     Я сталкивалась с такой ситуацией, когда UI приложения был сформирован таким образом, что реальный пользователь мог кликнуть мышкой по кнопке, но при использовании стандартного метода Mouse.Click(control) выходило исключение, говорящее о том, что это контрол заблокирован (хотя на самом деле он не был заблокирован). Эту проблему можно решить, создав метод расширения для класса Mouse фреймворка Coded UI, который позволит сделать клик на таком контроле:


    /// <summary>
    /// Класс расширений для работы с мышью.
    /// </summary>
    public static class MouseExtension
    {
        /// <summary>
        /// Осуществляет Click() левой кнопкой мыши, служит для заблокированых контролов.
        /// </summary>
        /// <param name="mouse">Мышь.</param>
        /// <param name="controlBoundingRect">BoundingRect контрола.</param>
        public static void ClickOnBlockingControl(this Mouse mouse, Rectangle controlBoundingRect)
        {
            Point clickablePoint = Point.Add(controlBoundingRect.Location,
                new Size(controlBoundingRect.Width / 2, controlBoundingRect.Height / 2));
            Mouse.Click(clickablePoint);
        }
    }

Тогда в коде какого-то метода, осуществляющего клик по контролу, этот метод расширения можно использовать следующим образом:

Mouse.Instance.ClickOnBlockingControl(UIMyButton.BoundingRectangle);
           
Аналогично можно делать методы расширения для любых контролов. По такому принципу построены библиотеки утилит для работы с CodedUI тестами, о которых я писала ранее.