Мы продолжаем серию заметок о тестировании ПО на основе книги “Testing for Continuous Delivery with Visual Studio 2012″. В предыдущей заметке мы рассказывали об оптимальном цикле разработки и покрытии кода модульными тестами. В этой заметке рассмотрим как писать хорошие модульные тесты.
Существует много статей о том, как написать хороший модульный тест, и мы не считаем нужным писать об этом еще и здесь. Интересующиеся могут поискать в сети, по ключевым словам “шаблоны модульных тестов”.
Однако есть несколько особенно полезных советов.
Подготовка – Действие – Проверка
Общему подходу {Подготовка; Действие; Проверка} отдают предпочтение многие разработчики:
Подготовка: Подготовка тестовых данных;
Действие: Вызов тестируемого модуля;
Проверка: Сравнить ожидаемый и полученный результаты. И зарегистрировать, был ли результат сравнения успешным или нет.
Например:
|
1 2 3 4 5 6 7 8 9 10 |
[TestMethod] public void TestSortByFlavor() { // Подготовка: Подготовка тестовых данных: var catalog = new IceCreamCatalog(Flavor.Oatmeal, Flavor.Cheese); // Действие: Вызов тестируемого модуля: catalog.SortByFlavor(); // Проверка: Проверить и зарегистрировать результат: Assert.AreEqual(Flavor.Cheese, catalog.Items[0].Flavor); } |
Каждый тест должен осуществлять только одну проверку
Не стоит поддаваться искушению, создать тестовый метод, проверяющий более чем один аспект поведения модуля. Это ведет к тому, что тесты тяжело читать и менять. Кроме того, не всегда будет ясно, как интерпретировать проваленный тест.
Нужно всегда помнить, что тестовый фреймворк MSTest по умолчанию не гарантирует, что тесты будут выполняться в определенном порядке. Следовательно, нельзя переносить состояние из одного теста в другой. Однако в Visual Studio, можно использовать функцию Ordered Test, для выполнения тестов в определенной последовательности.
Используйте тестовые классы для того, чтобы проверять разные области поведения тестируемого кода
Разносите тесты для разного поведенческого функционала по отдельным тестовым классам. Обычно это работает хорошо, поскольку для тестирования разного функционала используются различные методы и общие функции. Если нужен доступ к некоторым методам из разных тестовых классов, их можно наследовать от общего абстрактного класса.
У каждого тестового класса могут быть методы TestInitialize и TestCleanup. (Это атрибуты MSTest; в других тестовых фреймворках есть эквиваленты, обычно называемые Setup and Teardown). Используйте методы инициализации или подготовки для выполнения общих задач, которые необходимы для настройки начальных условий для модульного теста. Например, создания объекта для тестирования, открытия соединений с базой данных или загрузки данных. Методы очистки или уничтожения вызываются всегда, даже если тестовый метод выполнился с ошибкой. Это полезный функционал, благодаря которому не надо писать весь свой тестовый код внутри блоков try…finally.
Тестируйте обработку исключений
Проверяйте, было ли выброшено нужное исключение в случае неправильных действий или входных данных. Можно использовать атрибут [ExpectedException], но стоит помнить: независимо от того, что именно в тесте станет причиной исключения, тест с данным атрибутом, будет пройден.
Более надежный способ тестировать исключения показан ниже:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
C# [TestMethod, Timeout(2000)] public void TestMethod1() { ... AssertThrows<InvalidOperationException>( delegate { MethodUnderTest(); }); } internal static void AssertThrows<exception>(Action method) where exception : Exception { try { method.Invoke(); } catch (exception) { return; // Ожидаемое исключение. } catch (Exception ex) { Assert.Fail("Выброшено неправильное исключение: " + ex.Message); } Assert.Fail("Ни одно исключение не было выброшено"); } |
Функция наподобие AssertThrows встроена во многие тестовые фреймворки.
Не тестируйте только одно входное значение или состояние
Проверка 2.0==МойМетодНахожденияКвадратногоКорня(4.0), не покажет того, что функция работает правильно для всех значений. Инструменты покрытия кода могут показать, что проверен весь код, но все равно есть вероятность того, что другие входные данные, или другие начальные состояния, или другие последовательности входных данных, дадут неверный результат.
Поэтому, мы рекомендуем тестировать репрезентативный набор входных данных, начальных состояний, и последовательности действий.
Ищите граничные случаи: такие, в которых есть особенные значения или особые отношения между значениями. Протестируйте эти граничные случаи и протестируйте репрезентативные значения между границами. Например, входные значения 0 и 1 могут считаться граничными для функции излечения квадратного корня, так как входные и выходные значения равны. Поэтому тестируйте, например, значения -10, -1, -0.5, 0, 0.5, 1, и 10.
Тестируйте во всем диапазоне. Если ваша функция должна работать для входных данных вплоть до 4096, попробуйте значения 4095 и 4097.
Подход тестирования от выбранной модели разделяет все пространство входных данных, состояний на границах полученных областей, и соответственно старается генерировать тестовые данные.
Для объектов более сложных, чем простые числовые функции, понадобится учитывать связи между разными состояниями и значениями: например, между списком и индексом в списке.
Отделяйте генерацию тестовых данных от проверки
Пост-условие – это булево выражение, которое всегда должно быть верно для входных и выходных значений или начального и конечного состояний тестируемого метода. Для того, чтобы протестировать простую функцию, можно написать:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
C# [TestMethod] public void TestValueRange() { while (GenerateDataForThisMethod( out string startState, out double inputValue))) { TestOneValue(startState, inputValue); } } // Параметризированный тестовый метод: public void TestOneValue(string startState, double inputValue) { // Подготовка – Установить начальное состояние: objectUnderTest.SetKey(startState); // Действие – Исполнение тестируемого метода: var outputValue = objectUnderTest.MethodUnderTest(inputValue); // Проверка – Проверить результат: Assert.IsTrue(PostConditionForThisMethod(inputValue, outputValue)); } // Определить отношения между входящими и исходящими значениями и состояниями: private bool PostConditionForThisMethod (string startState, double inputValue, double outputValue) { // Считать приемлемыми значения в определенном диапазоне: return startState.Length>0 && startState[0] == '+' ? outputValue > inputValue : inputValue < outputValue; } |
Для тестирования объекта, имеющего внутренне состояние, эквивалентный тест установит начальное состояние по тестовым данным и вызовет тестируемый метод. После чего вызовет проверку пост-условия, для сравнения начального и конечного состояния.
Преимущества такого разделения:
- Пост-условие непосредственно представляет текущие требования и может рассматриваться отдельно от вопросов, какие именно точки данных тестировать.
- Пост-условие может принимать диапазон значений; не обязательно указывать единственный правильный ответ для каждого входного значения.
- Генератор тестовых данных может меняться отдельно от пост-условия. Самым важным требованием к генератору данных является то, что он должен генерировать входные значения (или состояния) так, что они будут распределены вокруг граничных значений.
Генератор тестовых данных Pex
На закуску кратко упомянем Pex, дополнение для Visual Studio (существует и отдельная онлайн версия).
Pex автоматически генерирует тестовые данные, обеспечивающие высокое покрытие. Исследуя тестируемый код, этот полезный инструмент генерирует интересные входящие-выходящие значения. Скормите ему параметризированную версию тестового метода, и он сгенерирует тестовые методы, которые вызывают тест с различными аргументами.
