Тестирование программистом. Юнит-тесты. Фреймворки для тестирования

Сентябрь 5, 2022

Главная
Алгебра
Тестирование программистом. Юнит-тесты. Фреймворки для тестирования

Содержание

2. Введение Программисты не должны надеяться на то, что их код работает правильно должны доказывать корректность кода
3. Unit тесты Программисты тестируют сам код, а не результат щелчка по кнопке на сайте Unit-тест –
4. Когда пишутся тесты Мы создаем тесты по мере написания кода, не ожидая завершения написания всего приложения
5. Свойства хорошего unit теста Автоматизированный и повторяемый После написания тест должен остаться для последующего использования, чтобы
6. Свойства хорошего unit теста Любой участник разработки должен иметь возможность запустить unit тест Поэтому тесты должны
7. Хранение тестов Тесты можно хранить Снаружи проекта как отдельный проект в релиз будет уходить только код
8. Имя тест-кейса Юнит-тесты необходимо сопровождать как и обычный код поэтому важно выбирать правильные имена Имя тест-кейса
9. Именование тестов Много способов именования юнит-тестов Бывают соглашения по именованию внутри компании/отдела Именования тестового класса для
10. Фреймворки для тестирования Существует большое количество фреймворков для разных ЯП https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks Большинство фреймворков очень похожи, т.к.
11. Самый простой пример тест-кейса Тест-кейс должен начинаться с test Инфраструктура создания в unittest.TestCase В одном классе
12. Test runner Test runner запускает тесты и выдает результат Сколько тестов запустилось Если произошла ошибка Место
13. Тестирование калькулятора import unittest class Calc: def sum(self, a, b): return a + b class CalcTest(unittest.TestCase):
14. Список assert’ов
15. Дизайн тест-кейсов AAA - unit тест состоит из 3 частей Arrange – создаем все объекты, которые
16. Параметризованные тесты (parameterized) import unittest from parameterized import parameterized class Calc: def sum(self, a, b): return
18. Скачать презентацию

Слайд 2

Введение
Программисты
не должны надеяться на то, что их код работает правильно
должны

доказывать корректность кода снова и снова
Лучший способ доказать - автоматизированные тесты
Обычно программисты выполняют ручное тестирование
Автоматизированный тест
Пишется программистом
Запускается на компьютере
Во время тестирования
Тестировщик ищет баги
Программист убеждается в корректности программы

Слайд 3

Unit тесты
Программисты тестируют сам код, а не результат щелчка по кнопке

на сайте
Unit-тест – блок кода (обычный метод), который вызывает тестируемый блок кода и
Тестирует минимально возможный участок кода
Класс
Метод
Проверяет его правильность работы (сравнение ОР и ФР)
Тестируемый код
Тестируемая система (SUT, system under test)
Тестируемый класс (CUT, class under test)

Слайд 4

Когда пишутся тесты
Мы создаем тесты по мере написания кода, не ожидая

завершения написания всего приложения
Также как ручное тестирование
У нас может не быть UI или других классов, но мы все равно тестируем наш код

Слайд 5

Свойства хорошего unit теста
Автоматизированный и повторяемый
После написания тест должен остаться для

последующего использования, чтобы использовать как регрессионное тестирование
Должен легко запускаться и выполнятся быстро
Чтобы выполняться как можно чаще и программист не ленился их запускать
Простым в реализации
Чтобы программист не ленился писать юнит-тесты
Сложные тесты занимают много времени программиста
Написать юнит-тест не сложно, сложнее написать код, который будет поддерживать тестирование

Слайд 6

Свойства хорошего unit теста
Любой участник разработки должен иметь возможность запустить unit

тест
Поэтому тесты должны сохраняться в CVS (также как SUT)
Независимые (могут запускаться независимо)
Отсутствие побочных эффектов!

Слайд 7

Хранение тестов
Тесты можно хранить
Снаружи проекта как отдельный проект
в релиз будет уходить

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

Слайд 8

Имя тест-кейса
Юнит-тесты необходимо сопровождать как и обычный код
поэтому важно выбирать правильные

имена
Имя тест-кейса
объясняет для чего он нужен
другие программисты смогут понять для чего он нужен
помогает лучше разобраться нам самим, что мы тестируем
не понимая этого, мы не сможем написать тест (также как обычная функция)

Слайд 9

Именование тестов
Много способов именования юнит-тестов
Бывают соглашения по именованию внутри компании/отдела
Именования тестового

класса для Foo – FooTest
Каждый класс тестирует только одну сущность
Принцип именования тестов
[Тестирующийся метод]_[Сценарий]_[Ожидаемое поведение]

Слайд 10

Фреймворки для тестирования
Существует большое количество фреймворков для разных ЯП
https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
Большинство фреймворков очень

похожи, т.к. основаны на общей идее и имеет инфраструктуру (иерархию классов)
для создания тестов
Вспомогательные функции для assert’ов
для запуска тестов (test runners)
Во многих IDE есть поддержка тестовых фреймворков

Слайд 11

Самый простой пример тест-кейса
Тест-кейс должен начинаться с test
Инфраструктура создания в
unittest.TestCase
В

одном классе могут нахо-диться множество тест-кейсов
unittest.main() – предоставляет интерфейс командной строки

import unittest
class ExampleTest(unittest.TestCase):
def test_example(self):
self.assertEqual(3, 1+2)
self.assertTrue(3 == 1+2)
if __name__ == '__main__':
unittest.main()

Слайд 12

Test runner
Test runner запускает тесты и выдает результат
Сколько тестов запустилось
Если произошла

ошибка
Место ошибки
Причина ошибки
Существуют
Console runner
GUI runner
Тест-кейс и раннер независимы, поэтому можно использовать любой раннер.

Слайд 13

Тестирование калькулятора
import unittest
class Calc:
def sum(self, a, b):
return a +

b
class CalcTest(unittest.TestCase):
def test_sum(self):
calc = Calc()
actual_result = calc.sum(1, 2)
self.assertEqual(3, actual_result)
if __name__ == '__main__':
unittest.main()

Слайд 14

Список assert’ов

Слайд 15

Дизайн тест-кейсов
AAA - unit тест состоит из 3 частей
Arrange – создаем

все объекты, которые необходимы для выполнения тестирования
calc = Calc()
Act – выполняется тестируемый метод
actual_result = calc.sum(1, 2)
Assert – сравнение ожидаемого и фактического результата
self.assertEqual(3, actual_result)

Слайд 16

Параметризованные тесты (parameterized)
import unittest
from parameterized import parameterized
class Calc:
def sum(self, a,

b):
return a+b
class CalcTest(unittest.TestCase):
@parameterized.expand([
("1 2", 1, 2, 3),
("2 5", 2, 5, 7),
])
def test_add(self, _, a, b, expected):
calc = Calc()
actual_result = calc.sum(a, b)
self.assertEqual(expected, actual_result)

Тестирование программистом. Юнит-тесты. Фреймворки для тестирования

Содержание

ВведениеПрограммисты не должны надеяться на то, что их код работает правильнодолжны

Unit тестыПрограммисты тестируют сам код, а не результат щелчка по кнопке

Когда пишутся тестыМы создаем тесты по мере написания кода, не ожидая

Свойства хорошего unit тестаАвтоматизированный и повторяемыйПосле написания тест должен остаться для

Свойства хорошего unit тестаЛюбой участник разработки должен иметь возможность запустить unit

Хранение тестовТесты можно хранитьСнаружи проекта как отдельный проектв релиз будет уходить

Имя тест-кейсаЮнит-тесты необходимо сопровождать как и обычный кодпоэтому важно выбирать правильные

Именование тестовМного способов именования юнит-тестовБывают соглашения по именованию внутри компании/отделаИменования тестового

Фреймворки для тестированияСуществует большое количество фреймворков для разных ЯПhttps://en.wikipedia.org/wiki/List_of_unit_testing_frameworksБольшинство фреймворков очень

Самый простой пример тест-кейсаТест-кейс должен начинаться с testИнфраструктура создания вunittest.TestCase В

Test runnerTest runner запускает тесты и выдает результатСколько тестов запустилосьЕсли произошла

Тестирование калькулятораimport unittestclass Calc: def sum(self, a, b): return a +