пятница, 2 ноября 2012 г.

Проверки. Часть 3. Типы проверок.

Хочу рассказать свою точку зрения на то, какие бывают проверки и как можно выводить результаты наших проверок при выполнении автотеста. Этот вопрос уже обсуждался не один раз, и не в одном месте (например, очень хорошее обсуждение тут). Расскажу решение, которое выбрала я и применяю его в практике.

Я делю все проверки на 2 части:
1. Проверки, проверяющие промежуточные состояния.
2. Проверки, проверяющие тестируемую функциональность.

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

Проверки, проверяющие тестируемую функциональность.

 Для проверок второго типа все просто, мы используем стандартный класс любого Unit-testing фреймворка Assert или класс Verify. В таком случае результат будет выглядеть примерно так:

Assert.AreEqual failed. Expected:<6>. Actual:<-10>. После ввода некорректных данных «-10» в поле количества товара и перемещения фокуса валидация прошла некорректно.

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

Проверки, проверяющие промежуточные состояния.

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


Test method Testing.UITests.Tests.SomeTestMethod() threw exception: 
System.ArgumentOutOfRangeException: Индекс за пределами диапазона. Индекс должен быть положительным числом, а его размер не должен превышать размер коллекции.
Имя параметра: index

или с такой


Метод проверки Testing.UITests.OrganizationList.ViewOrganizationsPropertiesTestFixture.ПросмотрИнформацииОПредприятии выдал исключение: Microsoft.VisualStudio.TestTools.UITest.Extension.UITestControlNotFoundException: Дополнительные сведения При воспроизведении не удалось найти элемент управления с указанными свойствами поиска.: 
TechnologyName:  "UIA"
ControlType:  "Edit"
AutomationId:  "24763E55-DB6E-4A65-9545-5301D251FC72"

Но эти сообщения об ошибках не очень человеко-читаемы. Для вывода более понятных сообщений можно использовать проверки промежуточного состояния. Но для этого лучше использовать не Asssert, а бросать какое-либо исключение с понятным сообщением. Что нам это даст - при просмотре результатов запуска тестов в случае падения нам сразу будет понятно, что ошибка произошла не при проверке тестируемой функциональности. Понятное сообщение об ошибке может сразу подсказать нам, в чем именно заключается ошибка в тесте (например, поменялся AutomationId у контрола, либо немного поменялся сам ход сценария, например, раньше мы принимали за данное, что фокус уже стоит на каком-то элементе, а новое поведение - фокус на элемент надо ставить вручную). Можно использовать либо стандартные исключения, либо создать какое-то свое пользовательское и кидать его. Например,  я могу создать исключение TestExecutionException и кидать его в случае fail'а теста из-за невыполнения промежуточной проверки.


Пример (C#). Нам на определенном шаге теста нужно проверить, что таблица наименований товара не пустая.

if (Goods.Count == 0)
{
  throw new TestExecutionException("В таблице товаров нет ни одного товара.");
}

Тогда текст сообщения об ошибке будет следующим:

Test method Testing.UITests.Tests.SomeTestMethod() threw exception:
Testing.Common.TestExecutionException: В таблице товаров нет ни одного товара

Если лень читать Msdn, вот как создать пользовательское исключение:

    [Serializable]
    public class TestExecutionException : Exception
    {
        public TestExecutionException()
        {
        }
 
        public TestExecutionException(string message)
            : base(message)
        {
        }
 
        public TestExecutionException(string message, Exception innerException)
            : base(message, innerException)
        {
        }
 
        protected TestExecutionException(SerializationInfo info, StreamingContext context) : base(info, context)
        {
        }
    }




Комментариев нет:

Отправить комментарий