Transcript Software Design Модульное тестирование Бреслав А. А. Код постоянно модифицируется Добавление новых функций  Исправление ошибок  Улучшение дизайна (рефакторинг)   Каждое изменение кода может внести ошибку Бреслав А.

Software Design
Модульное тестирование
Бреслав А. А.
Код постоянно модифицируется
Добавление новых функций
 Исправление ошибок
 Улучшение дизайна (рефакторинг)


Каждое изменение кода может внести
ошибку
Бреслав А. А.
Паттерны проектирования. Введение
Защита от ошибок при
модификации


Статические проверки
Динамические проверки
 Контракт
 Утверждения

(assertions)
Тестирование
 Приемочное (acceptance tests)
 проверка системы в целом или ее крупных частей
 Модульное (блочное, unit tests)
 проверка отдельных методов
Бреслав А. А.
Паттерны проектирования. Введение
Необходимость тестирования
Статические проверки не позволяют
обнаружить логические ошибки
 Не все динамические проверки
обязательно выполнятся при
отладочном запуске
 Тесты позволяют гарантировать, что
проверка состоялась

Бреслав А. А.
Паттерны проектирования. Введение
Кто тестирует

QA-инженер (тестер)
 Приемочные
тесты
 Со значительной задержкой

Разработчик
 Не
только приемочные, но и блочные тесты
 Как только понадобится
Бреслав А. А.
Паттерны проектирования. Введение
Автоматические тесты

Тестировать вручную слишком долго и
скучно 
 Что-нибудь
забудешь

проверить обязательно
Если каждый тест – это программа, то
один разработчик может
протестировать весь проект при каждом
изменении кода
Бреслав А. А.
Паттерны проектирования. Введение
Старый анекдот 
― Папа,
почему Солнышко каждый день
встает?
― Откуда ты знаешь? Ты проверял?
Работает? Каждый день работает?
Тогда сынок, ради Бога, НИЧЕГО НЕ
ТРОГАЙ!
У папы не было автоматических тестов 
Бреслав А. А.
Паттерны проектирования. Введение
Тесты не должны быть
«полуавтоматическими»


Код теста должен однозначно говорить,
правильно работает программа или нет
Если человеку необходимо проверить, что
 на
экран выводится нужная последовательность
чисел
 нужные файлы созданы и имеют нужный размер
…
то это уже не автоматические тесты
Бреслав А. А.
Паттерны проектирования. Введение
Тесты не должны быть
случайными
Автоматический тест должен находить
ошибку ВСЕГДА
 Тест на случайных данных сообщает,
что ошибка есть, но не позволяет ее
обнаружить
 Случайные данные тесты можно
применять для поиска тестовых
случаев, а не для проверки

Бреслав А. А.
Паттерны проектирования. Введение
Автоматизация тестов

Приемочные
 Сложно
создать систему для приемочного
тестирования GUI
 Долго писать тестовые сценарии

Модульные
 Просто
писать
 Позволяют обнаружить значительную часть
ошибок
Бреслав А. А.
Паттерны проектирования. Введение
Блочные тесты

Проверяем маленькие участки
функциональности
 часто

это отдельные методы
Создаем в процессе разработки
 Возможно
даже ДО написания
тестируемого кода

Запускаем после каждой модификации
системы
Бреслав А. А.
Паттерны проектирования. Введение
Польза от тестов
Улучшение понимания системы ее
разработчиком
 Раннее обнаружение ошибок
 Уверенность при модификации кода
 Дополнительное описание
функциональности
 Улучшение API

Бреслав А. А.
Паттерны проектирования. Введение
Когда писать и запускать тесты

При создании нового кода
 Писать
и запускать тесты вместо отладочных
запусков кода
 Создавать тесты как можно раньше

При обнаружении ошибки
 Написать
тест, воспроизводящий ошибку
 Исправить ошибку
 Убедиться, что все тесты проходят без ошибок
Бреслав А. А.
Паттерны проектирования. Введение
Масштаб одного теста
Один тест – один сценарий
использования
 Не нужно тестировать все одним тестом
 Даже если тестируется один метод
часто бывают нужны несколько тестов

Бреслав А. А.
Паттерны проектирования. Введение
Полнота тестирования
Невозможно быстро создать полную
систему тестов
 С этим нужно смириться
 Неполные тесты лучше отсутствия
тестов
 Обнаружатся ошибки – добавим еще
тестов

Бреслав А. А.
Паттерны проектирования. Введение
JUnit

Авторы: Эрих Гамма и Кент Бек
3 использует reflection
 JUnit 4 использует аннотации
 JUnit
Тест – это метод
 Тесты объединяются в классы

 Обычно
один класс тестов соответствует
одному классу системы
Бреслав А. А.
Паттерны проектирования. Введение
Пример: тесты для стека (1)
public class StackTests extends TestCase {
public void testPush() {
Stack s = new Stack();
s.push(“abc”);
s.push(“abc”);
assertTrue(s.size() == 2);
}
Бреслав А. А.
Паттерны проектирования. Введение
Пример: тесты для стека (2)
public void testPop() {
Stack s = new Stack();
s.push(“abc”);
s.push(“def”);
assertEquals(s.pop(), “def”);
assertTrue(s.size() == 1);
}
Бреслав А. А.
Паттерны проектирования. Введение
Пример: тесты для стека (3)
public void testPopFail() {
Stack s = new Stack();
try {
s.pop();
fail();
} except (StackUnderflowException e) {
}
}
Бреслав А. А.
Паттерны проектирования. Введение
JUnit 3
Базовый класс TestCase
 Имя тестового метода начинается со
слова test
 assertTrue(), assertFalse(),
assertEquals(), assertNull(),
assertNotNull(), assertSame()
 fail() – тест не прошел

Бреслав А. А.
Паттерны проектирования. Введение
JUnit 4
Базового класса нет
 Имя метода любое
 Аннотация @Test
 Класс Assert

 статические
Бреслав А. А.
методы assert*()
Паттерны проектирования. Введение
Фикстура (fixture)

Часто для запуска каждого теста
требуется создать и
проинициализировать объект
тестируемого класса
 Тесты

стека: создать стек
Метод setUp() запускается перед
вызовом каждого теста
 JUnit
Бреслав А. А.
4: @Before
Паттерны проектирования. Введение
Внешняя фикстура

Иногда фикстура задействует внешние
ресурсы
 файлы
 сетевые
соединения
…

Метод tearDown() запускается после
каждого теста
 JUnit
Бреслав А. А.
4: @After
Паттерны проектирования. Введение
Общая фикстура

JUnit 4
 @BeforeClass
– перед запуском тестов из
этого класс
 @AfterClass – после окончания работы
тестов из этого класса
Бреслав А. А.
Паттерны проектирования. Введение
Наборы тестов

Запускать классы тестов по одному неудобно
 JUnit

public class AllTests {



Бреслав А. А.
3: TestSuite, метод suite()
public static Test suite() {
 TestSuite suite = new TestSuite(“Suite");
 suite.addTest(TestStack.class);
 suite.addTest(TestQueue.class);
 return suite;
}
}
Паттерны проектирования. Введение
Test-Driven Development (XP)

Сначала тесты – потом код
 Написать
тест
 Сделать так, чтобы все скомпилировалось

ТОЛЬКО СКОМПИЛИРОВАЛОСЬ
 Убедиться,
что тест не проходит
 Сделать минимум действий, чтобы этот тест
проходил
 Убедиться, что тест проходит
 Устранить все дублирование
Бреслав А. А.
Паттерны проектирования. Введение
Чем это хорошо
Сначала думаем, потом пишем
 Тесты помогают понять, что нужно
сделать следующим шагом
 Тест является заказом «идеального
API»
 То, что тест сначала не проходит – это
«тест для теста»

Бреслав А. А.
Паттерны проектирования. Введение
Некоторые рекомендации
Начинать тест с assert*()
 Использовать понятные тестовые
данные
 Использовать тесты, чтобы понять, как
что-то работает
 Нашли ошибку – сразу напишите тест

Бреслав А. А.
Паттерны проектирования. Введение
Источники
1.
Бек К., Экстремальное
программирование: разработка
через тестирование. Библиотека
программиста. – СПб.: Питер,
2003. – 224 с.: ил.
Бреслав А. А.
Паттерны проектирования. Введение
Вопросы
Бреслав А. А.
Паттерны проектирования. Введение