Документ подробно описывает различные виды тестирования программного обеспечения, включая функциональное, производительность, нагрузочное и другие. Также рассматриваются методы использования JUnit 4 для написания тестов, аннотации для организации тестов и концепция разработки через тестирование (TDD). Особое внимание уделяется структуре тестов, утверждениям и правилам, которые помогают в эффективном тестировании.

1. Unit тестирование
Виталий Унгурян
unguryan@itstep.org

2. Тестирование

3. Качество программного обеспечения
КПО можно определить как совокупную
характеристику исследуемого ПО с
учётом следующих составляющих:
 надёжность,
 сопровождаемость,
 практичность,
 эффективность,
 мобильность,
 функциональность.

4. Классификация видов тестирования
По объекту тестирования:
Функциональное тестирование
Тестирование производительности
 Нагрузочное тестирование
 Стресс-тестирование
 Тестирование стабильности
Конфигурационное тестирование
Юзабилити-тестирование
Тестирование интерфейса пользователя
Тестирование безопасности
Тестирование локализации
Тестирование совместимости

5. Классификация видов тестирования
По знанию системы:
Тестирование чёрного ящика
Тестирование белого ящика
Тестирование серого ящика

6. Классификация видов тестирования
По степени автоматизации
Ручное тестирование
Автоматизированное
тестирование
Полуавтоматизированное
тестирование

7. Классификация видов тестирования
По степени изолированности
компонентов
Модульное тестирование
Интеграционное
тестирование
Системное тестирование

8. Классификация видов тестирования
По времени проведения
тестирования
Альфа-тестирование
 Дымовое тестирование (англ. smoke testing)
 Тестирование новой функции (new feature testing)
 Подтверждающее тестирование
 Регрессионное тестирование
 Приёмочное тестирование
Бета-тестирование

9. Классификация видов тестирования
По признаку позитивности
сценариев
Позитивное тестирование
Негативное тестирование

10. JUnit 4
Test-case это методы,
которые помечаются
аннотациям.

11. @Test
Аннотация @Test помечает метод,
делая его тестовым.
Тестовые методы должны
начинаться с public void.
В тестовых методах размещается
код проверки.

12. @Test
Кроме того, у данной аннотации
есть два параметра,
expected — задаёт ожидаемое
исключение и
timeout — задаёт время, по
истечению которого тест считается
провалившимся.

13. Утверждения
Сами тесты состоят из выполнения
некоторого кода и методов
утверждений.
Утверждения чаще всего
выполняются с помощью
класса Assert хотя иногда
используют ключевое слово assert.

14. Утверждения
fail(String) Указывает на то что бы
тестовый метод упадет при этом
выводя текстовое сообщение об
ошибке.

15. Утверждения
assertSame([String], expected,
actual)
Проверяет, что обе переменные
относятся к одному объекту
(имееют одинаковые ссылки).

16. Утверждение эквивалентности
assertsEquals([String message],
expected, actual)
expected - ожидаемое значение
контролируемого аргумента.
actual - действительное значение.
Проверяет, что два значения
совпадают по содержимому.

17. Утверждения
assertTrue([message], boolean
condition) Проверяет, что
логическое условие истинно
assertFalse([message], boolean
condition) Проверяет, что
логическое условие ложно

18. Утверждения
assertNull([message], object)
Проверяет, что объект является
пустым null.
assertNotNull(([message], object)
Проверяет, что объект не является
пустым null.[message], object)

19. Фикстуры
Сценарии тестов могут нуждаться в
некоторых действиях,
предшествующих тесту (наполнение
БД) или выполняющихся после него
(очистка БД).
Для этого существуют так
называемые фикстуры.

20. @Before
Аннотация @Before обозначает
методы, которые будут вызваны до
исполнения теста, методы должны
быть public void. Здесь обычно
размещаются предустановки для
теста.

21. @After
Аннотация @After обозначает
методы, которые будут вызваны
после выполнения теста, методы
должны быть public void. Здесь
размещаются операции
освобождения ресурсов после
теста.

22. @BeforeClass
Аннотация @BeforeClass обозначает
методы, которые будут вызваны до
создания экземпляра тест-класса,
методы должны быть public static void.
Имеет смысл размещать предустановки
для теста в случае, когда класс содержит
несколько тестов использующих
различные предустановки.

23. @AfterClass
Аннотация @AfterClass связана по
смыслу с @BeforeClass, но
выполняет методы после теста,
методы должны быть public static
void.

24. Правила @Rule
@Rule - это некое подобие утилит
для тестов, которые добавляют
функциональность до и после
выполнения теста.

25. Запускалки @RunWith
Запуск теста может быть
сконфигурирован с помощью@RunWith.
При этом класс, указанный в аннотации
должен наследоваться от Runner.
JUnit4 — запускалка по умолчанию, как понятно из
названия, предназначена для запуска JUnit 4 тестов.
JUnit38ClassRunner предназначен для запуска тестов,
написанных с использованием JUnit 3.

26. Запускалки @RunWith
JUnit4 — запускалка по умолчанию, как
понятно из названия, предназначена
для запуска JUnit 4 тестов.
JUnit38ClassRunner - предназначен для
запуска тестов, написанных с
использованием JUnit 3.

27. Запускалки @RunWith
@SuiteMethod либо @AllTests тоже
предназначены для запуска JUnit 3
тестов. В отличие от предыдущей
запускалки, в эту передается класс
со статическим методом suite
возвращающим тест
(последовательность всех тестов).

28. Запускалки @RunWith
@Suite — эквивалент предыдущего,
только для JUnit 4 тестов. Для
настройки запускаемых тестов
используется аннотация @SuiteClasses.
@Enclosed — то же, что и предыдущий
вариант, но вместо настройки с
помощью аннотации используются все
внутренние классы.

29. Запускалки @RunWith
@Categories — попытка
организовать тесты в
категории(группы). Для этого
тестам задается категория с
помощью @Category, затем
настраиваются запускаемые
категории тестов в сюите.

30. Запускалки @RunWith
@Parameterized — довольно
интересная запускалка, позволяет
писать параметризированные тесты.
Для этого в тест-классе объявляется
статический метод возвращающий
список данных, которые затем будут
использованы в качестве аргументов
конструктора класса.

31. Запускалки @RunWith
@Theories — чем-то схожа с
предыдущей, но параметризирует
тестовый метод, а не конструктор.
Данные помечаются с помощью
@DataPoints и @DataPoint,
тестовый метод — с
помощью @Theory.

32. Порядок запуска тестов
Важно!
В JUnit предполагается, что все
тестируемые методы могут быть
выполнены в произвольном
порядке. Поэтому тесты не должны
зависеть от других тестов.

33. Разработка через тестирование
Разработка через тестирование
(test-driven development, TDD) —
техника разработки программного
обеспечения, которая
основывается на повторении очень
коротких циклов разработки.

34. Разработка через тестирование
Цикл разработки:
В начале пишется тест,
покрывающий желаемое
изменение, затем пишется код,
который позволит пройти тест.

35. Разработка через тестирование
Разработка по TDD требует от
разработчика создания
автоматизированных модульных
тестов, определяющих требования
к коду непосредственно перед
написанием самого кода.

36. Разработка через тестирование
Тест содержит:
Проверки условий, которые могут
либо выполняться, либо нет.
Когда они выполняются, говорят, что
тест пройден. Прохождение теста
подтверждает, предполагаемое
поведение кода написанного
программистом.

37. Разработка через тестирование
Автор подхода TDD Кент Бек
выделяет пять основных этапов при
использовании методологии на
практике.

38. Разработка через тестирование
1.Написать новый тест-кейс;
2.Убедиться, что запуск нового теста
приведет к сбою;
3.Написать новый или модифицировать
код так, чтобы тест прошел успешно;
4.Перезапустить все остальные тесты и
подтвердить успешное их прохождение;
5.Сделать рефакторинг кода, устранив
избыточность.

39. Разработка через тестирование

40. Разработка через тестирование