Всем привет. Много времени мы предоставили рассмотрению автоматизации интерфейса (UI). Давайте же уделим внимание и рассмотрению юнит и интеграционной автоматизации.
Юнит (модульное) тестирование – это написание дополнительного кода с целью проверки мельчайших блоков функционального кода, чтобы убедиться, что они работают без ошибок.
Код обычно разрабатывается на классы или объекты. Термин “класс”, а термин “объект”, как правило, используются как взаимозаменяемые. Классы состоят из переменных и функций, которые включают конструкторы, методы и свойства, но они могут также включать расширяемые классы.
Для каждого объекта в коде, вы должны иметь модульный тест (Unit test) для этого объекта. Юнит тесты должны гарантировать, что каждая строка из вашего функционального кода работает, как ожидалось.
Тестовое покрытие
Unit Test выполняет строки функционального кода, который нужно проверить. Представьте себе, что у вас есть 100 строк кода и блок юнит тестов проверяют только 50. Таким образом, можно гарантировать, что только 50% кода, работает, как ожидается.
Такие инструменты, как MSTest, MBUnit, NUnit, и другие могут предоставлять отчеты об охвате кода.
Категории модульных тестов
- Тестирование изолированного кода
- Тесты логики “поведения”
- Тестирование API
Более детально рассмотрим каждую в отдельных статьях.
NUnit
В нашем проекте мы будем использовать наиболее часто используемый NUnit. Нам понадобятся знания основных его аннотаций и класса проверок Assert.
Основные аннотации:
- [TestFixture]
- [Test]
Синтаксис Assert:
- Классическая реализация: Assert.AreEqual(…), Assert.IsTrue(…) и т.д.
- Поверка ограничений: Assert.That(…)
Тестируемое приложение
Давайте рассмотрим тестируемое приложение. Основное его предназначение – проверка кредитной истории заемщиков.
Приведу листинг классов и интерфейсов приложения.
В классе CreditCardApplication создается всего лишь два свойства – имени и возраста кредитора:
|
1 2 3 4 5 6 7 8 9 |
namespace BankingSite { public class CreditCardApplication { public string ApplicantName { get; set; } public int ApplicantAgeInYears { get; set; } // etc. } } |
Класс BankingSite содержит конструктор для инициализации объекта интерфейса, а также метод, который определяет, положительная или негативная история у заемщика:
|
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 |
namespace BankingSite { public class CreditCardApplicationScorer { private readonly ICreditCheckerGateway _creditCheckerGateway; public CreditCardApplicationScorer(ICreditCheckerGateway creditCheckerGateway) { _creditCheckerGateway = creditCheckerGateway; } public bool ScoreApplication(CreditCardApplication application) { var isApplicantTooYoung = application.ApplicantAgeInYears < 21; if (isApplicantTooYoung) { return false; } var hasGoodCreditHistory = _creditCheckerGateway.HasGoodCreditHistory(application.ApplicantName); return hasGoodCreditHistory; } } } |
И сам интерфейс ICreditCheckerGateway, содержащий один единственный метод, который мы реализуем в предыдущем классе.
|
1 2 3 4 5 6 7 |
namespace BankingSite { public interface ICreditCheckerGateway { bool HasGoodCreditHistory(string personsName); } } |
В следующей статье рассмотрим unit-тестирование изолированного кода на примере этого приложения.