C# Desktop. Занятие 17.

Темы лекции: Unit-тестирование.
Практическое задание: Unit-тестирование.
Тренер: Игорь Шкулипа, к.т.н.
Платформа .Net и язык программирования C#.
Занятие 17

http://www.slideshare.net/IgorShkulipa 2
Модульное тестирование
Unit testing (юнит тестирование или модульное тестирование) —
заключается в изолированной проверке каждого отдельного элемента
путем запуска тестов в искусственной среде.
Unit (Элемент) — наименьший компонент, который можно
скомпилировать.
Драйверы — модули тестов, которые запускают тестируемый элемент.
Заглушки — заменяют недостающие компоненты, которые вызываются
элементом и выполняют следующие действия:
• возвращаются к элементу, не выполняя никаких других действий;
• отображают трассировочное сообщение и иногда предлагают
тестировщику продолжить тестирование;
• возвращают постоянное значение или предлагают тестеру самому
ввести возвращаемое значение;
• осуществляют упрощенную реализацию недостающей
компоненты;
• имитируют исключительные или аварийные условия.

Подходы к unit-тестированию
White-box testing. Для конструирования тестов используются
внутренняя структура кода и управляющая логика. При этом существует
вероятность, что код будет проверяться так, как он был написан, а это не
гарантирует корректность логики.
Black-box testing. Для конструирования тестов используются требования
и спецификации ПО.
Недостатки:
• таким способом невозможно найти взаимоуничтожающихся
ошибок,
• некоторые ошибки возникают достаточно редко (ошибки работы с
памятью) и потому их трудно найти и воспроизвести

Стратегия модульного тестирования
Модульное тестирование является одной из ключевых практик
методологии экстремального программирования:
• Написание тестов помогает войти в рабочий ритм
• Придает уверенность в работоспособности кода.
• Дает запас прочности при дальнейшей интеграции или изменениях
кода.
Модульное тестирование оправдано, если оно:
• Снижает время на отладку
• Дает возможность поиска ошибок с меньшими затратами, нежели
при других подходах
• Дает возможность дешевого поиска ошибок при изменениях кода в
дальнейшем

Цель модульного тестирования
Получение работоспособного кода с наименьшими затратами. И его применение
оправдано тогда и только тогда, когда оно дает больший эффект, нежели другие
методы.
Отсюда следует несколько выводов:
• Нет смысла писать тесты на весь код. Некоторые ошибки проще найти
на более поздних стадиях. Так, например, для ООП данное правило может
звучать так: нет смысла писать тесты на класс, который используется
только одним классом. Эффективней написать тесты на вызывающий класс
и создать тесты тестирующие все участки кода.
• Писать тесты для кода потенциально подверженного изменениям
более выгодно, чем для кода, изменение которого не предполагается.
Сложная логика меняется чаще, чем простая. Следовательно, в первую
очередь имеет смысл писать модульные тесты на сложную логику. А на
простую логику писать позднее или вообще тестировать другими методами.
• Для того чтобы как можно реже изменять тесты следует хорошо
планировать интерфейсы. То же самое можно сказать и применительно к
написанию исходного кода. Действительно, создание хорошей архитектуры
часто определяет дальнейший ход проекта. И есть оптимум, на каком этапе
архитектура «достаточно хороша».

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

TDD
TDD (Test-Driven Development) - это методика разработки, позволяющая
оптимизировать использование модульных тестов. Стоит подчеркнуть,
что речь идет именно об оптимальном, а не максимальном
применении. Задача, которую преследует TDD, - достижение баланса
между усилиями и результатом.
С практической точки зрения, основой TDD является цикл
«red/green/refactor»:
• в первой фазе программист пишет тест,
• во второй - код, необходимый для того, чтобы тест работал,
• в третьей, при необходимости, производится рефакторинг.
В соответствии с принципом "Test First", следует писать только такой
код, который абсолютно необходим, чтобы тесты выполнялись
успешно.

Пример. Создание теста

Класс-тест
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace UnitTestProject1
{
[TestClass]
public class UnitTest1
{
[TestMethod, ExpectedException(typeof(ArgumentException))]
public void TestMethod1()
{
TDDExample.FactorialClass.Factorial(-1);
}
}
}

Тестируемый класс
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Numerics;
namespace TDDExample
{
public class FactorialClass
{
public static BigInteger Factorial(int number)
{
if (number < 0) throw new
ArgumentException("Argument is Less than Zero.");
if (number == 0) return 1;
else return Factorial(number - 1) * number;
}
}
}

Запуск теста

Тест с другими данными
14
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace UnitTestProject1
{
[TestClass]
public class UnitTest1 {
public void TestMethod1()
{
TDDExample.FactorialClass.Factorial(10);
}
}
}

Класс Assert
Проверяет условия, использующие утверждения "истина/ложь", в процессе
модульных тестов.
Пространство имен: Microsoft.VisualStudio.TestTools.UnitTesting
Методы:
• AreEqual, AreEqual<T> / AreNotEqual, AreNotEqual<T> + 17 перегрузок -
проверяет два указанных объекта на равенство/неравенство. Утверждение не
выполняется, если объекты не равны.
• AreSame / AreNotSame + 2 перегрузки - проверяет, ссылаются ли две
указанные объектные переменные на один и тот же объект / на разные объекты.
• Equals - определяет равенство двух объектов.
• Fail - отменяет выполнение утверждения без проверки каких-либо условий.
• Inconclusive - указывает, что утверждение не может быть проверено.
• IsFalse / IsTrue - проверяет, имеет ли указанное условие значение false/true.
• IsInstanceOfType / IsNotInstanceOfType - проверяет, является / не является
ли указанный объект экземпляром заданного типа.
• IsNull / IsNotNull - проверяет, имеет / не имеет ли указанный объект значение
null
• ReplaceNullChars - заменяет в строке символы null ('0') на "0".

Пример. Тестируемый класс
public class FactorialClass
{
public static BigInteger Factorial(int number)
{
if (number < 0) throw new
ArgumentException("Argument is Less than Zero.");
if (number == 0) return 1;
else return Factorial(number - 1) * number;
}
public static double CircleSquare(double radius)
{
return 3.14 * radius * radius;
}
public static double CircleLength(double radius)
{
return 2.0 * 3.14 * radius;
}
}

Пример. Класс-тест
[TestClass]
public class UnitTest1 {
public void TestFactorial() {
TDDExample.FactorialClass.Factorial(-100);
}
[TestMethod]
public void TestCircleSquare() {
double testRadius = 10;
double expectedResult = Math.PI * Math.Pow(testRadius, 2);
double actualResult = TDDExample.FactorialClass.CircleSquare(testRadius);
double tolerance=0.01;
Assert.AreEqual(expectedResult, actualResult, tolerance);
}
[TestMethod]
public void TestCircleLength() {
double testRadius = 10;
double expectedResult = 2.0 * Math.PI * testRadius;
double actualResult = TDDExample.FactorialClass.CircleLength(testRadius);
double tolerance = 0.01;
Assert.AreEqual(expectedResult, actualResult, tolerance);
}
}

Результат

Лабораторная работа №17. Unit-тестирование
В индивидуальных курсовых проектах при необходимости использовать
создание unit-тестов и TDD.

C# Desktop. Занятие 17.

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to C# Desktop. Занятие 17. (20)

More from Igor Shkulipa (20)

C# Desktop. Занятие 17.