вторник, 22 октября 2013 г.

Trello - доска для организации работы по методологии Kanban

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

пятница, 11 октября 2013 г.

Как быстрее проверять автотесты во время их разработки

    Ни для кого не секрет, что процесс выполнения UI автотестов не очень быстрый. А во время создания автотеста часто приходится запускать его на выполнение несколько раз и ждать, пока он пройдет. В целях экономии времени я использую несколько способов для сокращения времени проверки работоспособности теста во время его создания, о которых и хочу рассказать. Все примеры взяты из моего опыта, надеюсь, что-то будет полезно.
    Для начала опишу немного архитектуру тестового фреймворка. Инструменты - Visual Studio, C#, CodedUITest, MsTest.

Архитектура тестового фреймворка.

     Допустим, мы тестируем desktop-приложение, требующее определенное время на свою загрузку после запуска, например, 10-15 секунд. Нам невыгодно запускать приложение перед каждым тестом, и закрывать после каждого теста, поэтому мы решаем построить наш фреймворк по такой простой схеме:

  • все классы с тестами наследуются от базового класса RunAppTestFixtureBase
  • у этого класса есть метод, помеченный атрибутом [TestInitialize] (для unit-testing фрейморка Visual Studio, для других фреймворков атрибут может называться по-другому), который проверяет, запущено ли наше приложение, и в случае, если нет, запускает его.
    Таким образом, общую инициализацию тестов мы выносим в базовый класс. Этот метод инициализации может содержать какие-либо дополнительные действия, специфичные для тестирования вашего приложения.
  • В методе [TestCleanup] базового класса мы не указываем, что приложение должно закрываться. По окончании выполнения всех тестов оно закроется автоматически средствами MsTest.
    Отсюда сразу вытекает первый способ сокращения времени выполнения теста при его написании и отладке:

1 способ
     При отладке нет смысла каждый раз тратить время на ожидание запуска приложения. Мы можем запустить приложение один раз в самом начале. Таким образом, начиная со второго запуска нашего теста во время отладки мы уже экономим время.

2 способ
     В самом простом случае тест у нас состоит из трех логических частей - Setup, Execute и Assert - т.е. какие-то действия по установке начальных значений, непосредственно сами действия, которые мы тестируем, и проверки. 
     Предположим, у вас успешно прошли первые две логические части, а в последней части, части проверок, вы допустили ошибку - например, указали неверные тестовые данные. Вы ее исправляете, и нужно опять проверить, что тест работает хорошо. Поскольку части Setup и Execute уже отлажены, можно просто закомментировать их на время в тесте, привести приложение в то состояние, в котором оно будет после выполнения этих двух частей и запустить тест, в котором фактически выполнится только часть Assert. Это также сэкономит вам время.

3 способ
     У меня не раз случались ситуации, при которых были проблемы с действиями с некоторыми контролами. Например, CodedUI-фреймворк иногда считает контрол заблокированным и выдает исключение, что не может выполнить с ним необходимое действие, например, кликнуть мышкой. Или другая ситуация, когда не может найтись какой-то контрол. Представим, что действие с этим контролом у вас находится в середине или ближе к концу теста, и пока до него дойдет дело, вам нужно пройти кучу форм. Тут можно либо воспользоваться способом 2, либо создать отдельный проект, Sandbox, в котором проводить эксперименты с такими контролами. А потом найденное решение просто перенести в ваш проект.

среда, 9 октября 2013 г.

Работа с TFS. Определение тест-кейсов, несвязанных с тестовыми методами.

Привет, друзья!
Чтобы не заскучать на работе, и, конечно, быстрее выполнять поставленные передо мной задачи, я периодически думаю, как их можно автоматизировать, чтобы  в итоге сделать работу быстрее и интереснее. 
Как я рассказывала здесь, у нас настроен процесс автоматического запуска тестов на виртуальной машине. Одним из условий для успешного запуска является связь тест-кейса как Work Item из TFS с тестовым методом в какой-либо сборке с тестами. В Microsoft Test Manager это выглядит так:

Процесс связывания тест-кейса с тестовым методом достаточно нудный, я еще подумаю/погуглю насчет того, как его улучшить, обещаю :)
У меня иногда бывали случаи, когда я забывала связать уже имеющиеся тест-кейсы с методами. Либо наоборот, были написаны автотесты, но тест-кейсы для них еще не созданы. Проверять, какой же тест-кейс или тестовый метод не имеет привязки, очень скучно и долго. Поэтому я решила написать для этого несколько хелперов. Не забудьте подключить в проекте сборку Microsoft.TeamFoundation.TestManagement.Client.dll.

среда, 2 октября 2013 г.

Обходные пути в автоматизации тестирования при работе с TFS. Использование авторизации.

Всем привет.
В этот пасмурный (даже в Ростове-на-Дону) осенний денек хочется внести некоторые уточнения в мою предыдущую статью.
Там приводился код для работы с TFS, который успешно проходил в том случае, если вы уже подключены к TFS с использованием учетной записи, которая имеет соответствующие права доступа. В случае, если это не так, нужно выполнить аутентификацию в коде. Тогда наш код будет выглядеть следующим образом: