Модульное тестирование с помощью библиотеки NUnit Содержание

Модульное тестирование с помощью библиотеки NUnit

Содержание l l Мифы о тестировании Модульное тестирование с помощью NUnit Рекомендации к написанию тестов Полезная информация о C#

Введение l Что такое модульное тестирование? l l Тестирование отдельных функций системы. Как правило выполняется разработчиком модуля. Может быть легко автоматизировано. Закладывает основу для регрессионного тестирования приложения.

Мифы о тестировании l l «У меня нет времени на тесты» . «Тестирование – скучное и не творческое занятие» . «Мой код и так отлично работает» . «Это работа для отдела тестирования. У них получится лучше» .

Миф № 1 «У меня нет времени на тесты» Написание тестов стабилизирует код и позволяет существенно сократить время отладки. Недостаток времени Мало тестов Больше времени на отладку Нестабильный код Больше ошибок

Пример программы Пусть есть класс, реализующий математические функции. public class Calculator { public static int Sum(int x, int y){ return x+y; //возвращает результат сложения двух чисел } }

Вариант модульного тестирования № 1 Некоторые проверки можно поместить в сам класс. public class Calculator { public static void main(String[] args) { if (Sum(1, 3) == 4) { //проверяем, что при сложении 1 и //нам возвращается 4 3 Console. Write. Line("Test 1 passed. "); } else {Console. Write. Line("Test 1 failed. "); } }

Наблюдения l l l Тесты неудобно хранить в самой программе. Выход - внешняя библиотека, подключенная к проекту Часто используемые библиотеки модульного тестирования: NUnit, CUnit, JUnit, …

Библиотека Nunit

Пример тестового класса using System; using NUnit. Framework; [Test. Fixture] public class Largest. Test { [Test] public void Largest. Of. Number() { Assert. Greater(2, 1); } }

Tестовый проект l l l Как правило, имя_тестируемого_проекта + "Test“ (н-р Calculator. Test. dll) Тот же солюшен, что и тестируемый проект Разметка атрибутами NUnit l l l Test. Fixture. Set. Up Test Tear. Down Test. Fixture. Tear. Down

Атрибуты NUnit Атрибут Значение Test тестовый метод Test. Fixture атрибут класса, содержащего тесты Test. Fixture. Set. Up функция, выполняющаяся один раз при создании класса помеченного Test. Fixture Set. Up функция, выполняющаяся перед каждым тестом функция, выполняющаяся после Tear. Down исполнения каждого теста Test. Fixture. Tear. Down функция, выполняющаяся один раз при удалении класса помеченного Test. Fixture Ignore временное отключение теста Expected. Exception ожидаемый тип исключения для проверки "некорректных" данных

Проверка условий (Assert) l Класс Assert l l l Assert. Are. Equal – эквивалентны ли 2 параметра метода (пожалуй, самый популярный ассёрт) Is. True (Is. False) – является ли выражение истинным (ложным) Is. Null (Is. Not. Null) – является ли пaраметр null Contains – для коллекций и некоторые другие, которые редко имеет смысл использовать

Использование NUnit //подключение библиотеки using NUnit. Framework; //Тест должен быть помечен атрибутом [Test. Fixture] public class Calculator. Test { //тестирующие методы помечены атрибутом [Test] и начинаются с префикса “Test” [Test] public void Test. Sum() { int x = 3; int y = 5; int exp. Result = 8; int result = Calculator. Sum(x, y); //проверка условия на совпадение Assert. Are. Equal(exp. Result, result); //Assert. Are. Equals(Calculator. Sum(3, 5)); }

Причины ошибки тестов l l l Неправильно работает тестируемый метод. Методы, вызываемые из тестируемого, генерируют исключение по каким-то причинам. Некорректно написан тест.

Рекомендации к написанию тестов l l Название тестового метода. Размер теста. Ожидаемый результат. Тестовые данные.

Название тестового метода l Имя теста должно описывать: l l Тестируемую функциональность. Возможно, условия тестирования. Непонятно Test 1 Понятно Test. Add. User. Throw. Exception Test. Add. User. Without. Password

Размер теста l Тестовый метод должен быть коротким. l l Количество проверок (assert) должно быть минимальным. l l Дополнительные проверки -> вспомогательные методы. Иначе сложно будет найти причину ошибки. Каждый тест - одна единица бизнес-логики: l l l Простой метод. Один из исходов конструкции if. . else. Один из случаев (case) блока switch. Исключение, обрабатываемое блоком try…catch Исключение, генерируемое (throw) в методе.

Ожидаемый результат l l Ожидаемый результат должен быть константой. Не следует в тесте повторять тестируемую логику, подсчитывая результат. public void Test. Balance 1() { Account account = new Account(); account. Deposit(10); account. Withdraw(5); account. Deposit(6); int expected. Balance = 11; //правильно Assert. Are. Equal(expected. Balance, account. Balance); } public void Test. Balance 2() { Account account = new Account(); account. Deposit(10); account. Withdraw(5); account. Deposit(6); int expected. Balance = 10 - 5 + 6; //неправильно Assert. Are. Equal(expected. Balance, account. Balance); }

Тестовые данные l l Тестовые данные и ожидаемый результат должны быть рядом. Если объект user удобнее создавать вне тестового метода, следует использовать именованные константы. public void Test. Is. Password. Valid() { Assert. Is. True(user. Is. Password. Valid("abcdef")); //понять, правильно ли написан тест, можно лишь отыскав где создается объект user Assert. Is. False(user. Is. Password. Valid("123456")); }

Тестовые данные (cont. ) public void Test. Is. Password. Valid() { User user = new User("Name", "abcdef"); Assert. Is. True(user. Is. Password. Valid("abcdef")); //здесь все понятно Assert. Is. False(user. Is. Password. Valid("123456")); } public void Test. Is. Password. Valid() { Assert. Is. True(user. Is. Password. Valid(valid. Password)); //здесь тоже Assert. Is. False(user. Is. Password. Valid(wrong. Password)); }

Вопросы?