К содержимому
ИС30

Поиск по сайту

Конспекты, лабы, квизы, ЧаВо и страницы

Войти
Инструментальные средства разработки ПО
ИСРЛаба 4

Написание unit-тестов

Тесты на unittest для всех четырёх фигур из geometric_lib и план тестирования в отчёте.

Хегай Максим Вилорьевичдо 12 баллов
Дедлайн
пятница, 6 ноября
до 23:59
Через 28 днейДедлайн мягкий: сдать можно и позже, но лучше не тянуть
Войти, чтобы записаться на сдачу
Войдите

Задание

Среди всех тестов львиную долю занимают именно unit-тесты. В классическом понимании unit-тесты позволяют быстро и автоматически протестировать отдельные части ПО независимо от остальных.

В этой лабораторной работе мы рассмотрим простой пример создания unit-тестов. Работа основывается на задании первой лабораторной до удаления ветки, то есть со всеми фигурами: круг, треугольник, квадрат, прямоугольник.

Ручное тестирование

Начнём с простого варианта — ручного тестирования:

  1. Зная алгоритм нахождения периметра и площади фигуры, определяем наборы входных данных, которые будут переданы на вход программе.
  2. Зная входные данные, вручную просчитываем, какой ответ должна дать программа.
  3. Запускаем программу и передаём ей на вход исходные данные.
  4. Получаем ответ и сравниваем с ожидаемым. Если совпадают — идём к следующему набору данных, если нет — фиксируем ошибку в протоколе тестирования.

Unittest

Обычно Python поставляется уже с пакетом unittest. Если в вашей системе его нет, установите через pip.

Формат кода

  • Тесты должны быть написаны в классе.
  • Класс должен наследоваться от базового класса unittest.TestCase.
  • Имена всех функций-тестов должны начинаться с test.
  • Внутри функций должны быть вызовы операторов сравнения (assertX) — именно они проверяют полученные значения на соответствие заявленным.

Пример для нашей задачи

rectangle.py
import unittest
 
...
 
class RectangleTestCase(unittest.TestCase):
    def test_zero_mul(self):
        res = area(10, 0)
        self.assertEqual(res, 0)
 
    def test_square_mul(self):
        res = area(10, 10)
        self.assertEqual(res, 100)

Запускается этот код командой:

python -m unittest rectangle.py

В результате на экран будет выведено:

Успешный тест
C:\GSS\git_test>python -m unittest rectangle.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.001s
 
OK

Если в каком-нибудь из тестов будет обнаружена ошибка, unittest вернёт:

Проваленный тест
C:\GSS\git_test>python -m unittest rectangle.py
F.
======================================================================
FAIL: test_square_mul (rectangle.RectangleTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\GSS\git_test\rectangle.py", line 16, in test_square_mul
    self.assertEqual(res, 100)
AssertionError: 110 != 100
 
----------------------------------------------------------------------
Ran 2 tests in 0.002s
 
FAILED (failures=1)
Полезное замечание
Проваленный тест — тоже результат, а не ошибка, но из него нужно сделать соответствующие выводы. В этой лабораторной вы пишете не код приложения, а тесты для уже готового приложения, как если бы исходный код был вам недоступен.

Подготовка отчёта

В отчёте нужно написать план тестирования, который минимально содержит следующие пункты:

  1. Цели и задачи тестирования. Основные цели тестирования и задачи, которые необходимо достичь.
  2. Описание тестируемого продукта. Обзор функциональности, особенностей и требований к продукту, которые должны быть протестированы.
  3. Область тестирования. Конкретные функции, модули или компоненты продукта, которые будут исследованы.
  4. Стратегия тестирования. Общий подход, включая методы, техники и типы тестирования (функциональное, производительности, безопасности и т. д.).
  5. Критерии приёмки. Условия, которые должны быть выполнены для успешного завершения тестирования и приёмки продукта.
  6. Ожидаемые результаты. Отчёты о дефектах, статусы тестирования, метрики качества и другие данные.
  7. Актуальные результаты тестирования.
  8. Выводы из результатов тестирования.

Исходный код тестов должен лежать на GitHub (или в другом общедоступном репозитории), а в истории документа должен быть отражён факт появления тестов. При форматировании документа опирайтесь на опыт второй лабораторной работы.

Код фигур не менять
Тестами должны быть покрыты классы всех четырёх фигур из задания второй лабораторной. Исходный код самих фигур в процессе выполнения работы менять запрещено.

Требования

  • Тесты написаны на unittest: класс-наследник unittest.TestCase, методы начинаются с test, проверки через assertX.
  • Покрыты все четыре фигуры: круг, треугольник, квадрат, прямоугольник.
  • Исходный код фигур не изменён.
  • Тесты лежат в общедоступном репозитории, их появление видно в истории коммитов.
  • В отчёте есть план тестирования со всеми восемью пунктами, включая актуальные результаты и выводы.

Как сдавать

Отчёт с планом тестирования и ссылкой на репозиторий с тестами. Проваленные тесты не снижают оценку сами по себе, если в выводах объяснено, почему они провалились.

Материалы

Комментарии0

Пока никто ничего не написал.

Войдите, чтобы оставить комментарий