Модульное тестирование. Лабораторная работа № 6 Модульное тестирование. Лабораторная работа 3 модульное тестирование
 Скачать 233.38 Kb.
|
|
Лабораторная работа № 3 МОДУЛЬНОЕ ТЕСТИРОВАНИЕ 1. Цель работы Изучение возможности создания автоматических тестов, для модульного тестирования. 2. Оборудование Персональный компьютер. 3. Пояснения к работе Перед выполнением задания изучить лекционный материал и теоретические сведения. При выполнении лабораторной работы обучающийся должен Знать: - Основные принципы отладки и тестирования программных продуктов Уметь: - Выполнять отладку и тестирование программы на уровне модуля 4. Теоретические сведения Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны. Ключевые понятия юнит-тестирования Покрытие тестов (Code Coverage) — одна из главных оценок качества тестирования приложения. Это процент кода, который был покрыт тестами (0- 100%). На практике многие гонятся за этим процентом, с чем я не согласен, так как начинается навешивание тестов там, где они не нужны. Например, у нас в сервисе есть стандартные CRUD (create/get/update/delete) операции без дополнительной логики. Эти методы — сугубо посредники, делегирующие работу слою, работающему с репозиторием. TDD (Test-driven development) — разработка через тестирование. В рамках этого подхода в первую очередь пишется тест, который будет проверять определенный код. Получается тестирование чёрного ящика: мы знаем, что есть на входе и знаем, что должно получиться на выходе. Это позволяет избежать дублирования кода. Разработка через тестирование начинается с проектирования и разработки тестов для каждой небольшой функциональности приложения. В подходе TDD, во-первых, разрабатывается тест, который определяет и проверяет, что будет делать код. Основная цель TDD — сделать код более понятным, простым и без ошибок. Подход состоит из таких составляющих: 1. Пишем наш тест. 2. Запускаем тест, прошел он или нет (видим, что всё красное — не психуем: так и должно быть). 3. Добавляем код, который должен удовлетворить данный тест (запускаем тест). 4. Выполняем рефакторинг кода. Исходя из того, что модульные тесты являются наименьшими элементами в пирамиде автоматизации тестирования, TDD основан на них. С помощью модульных тестов мы можем проверить бизнес-логику любого класса. BDD (Behavior-driven development) — разработка через поведение. Это подход основан на TDD. Если говорить точнее, он использует написанные понятным языком примеры (как правило на английском), которые иллюстрируют поведение системы для всех, кто участвует в разработке. Не будем углубляться в данный термин, так как он в основном затрагивает тестировщиков и бизнес-аналитиков. Тестовый сценарий (Test Case) — сценарий, описывающий шаги, конкретные условия и параметры, необходимые для проверки реализации тестируемого кода. Фикстуры (Fixture) — состояние среды тестирования, которое необходимо для успешного выполнения испытуемого метода. Это заранее заданный набор объектов и их поведения в используемых условиях. Этапы тестирования Тест состоит из трёх этапов: 1. Задание тестируемых данных (фикстур). 2. Использование тестируемого кода (вызов тестируемого метода). 3. Проверка результатов и сверка с ожидаемыми. Чтобы обеспечить модульность теста, нужно нужно изолироваться от других слоев приложения. Сделать это можно помощью заглушек, моков и шпионов. Мок (Mock) — объекты, которые настраиваются (например, специфично для каждого теста) и позволяют задать ожидания вызовы методов в виде ответов, которые мы планируем получить. Проверки соответствия ожиданиям проводятся через вызовы к Mock-объектам. Заглушки (Stub) — обеспечивают жестко зашитый ответ на вызовы во время тестирования. Также они могут сохранять в себе информацию о вызове (например, параметры или количество этих вызовов). Такие иногда называют своим термином — шпион (Spy). Иногда эти термины stubs и mock путают: разница в том, что стаб ничего не проверяет, а лишь имитирует заданное состояние. А мок — это объект, у которого есть ожидания. Например, что данный метод класса должен быть вызван определенное число раз. Иными словами, ваш тест никогда не сломается из- за «стаба», а вот из-за мока может. 5. Задание Задание 1. Создание проекта программы, модули которого будут тестироваться по определенному алгоритму. 6. Порядок выполнения работы 1. Изучить теоретический материал. 2. Создать и запустить модульные тесты для управляемого кода, перейдя по ссылке https://docs.microsoft.com/ru-ru/visualstudio/test/walkthrough-creating-and- running-unit-tests-for-managed-code?view=vs-2019 . Примечание: внимательно изучить инструкции, предложенные в пошаговом руководстве. 3. Оформить отчёт. 7. Содержание отчета Отчет должен быть выполнен в соответствии с Общими требованиями к оформлению документов учебной деятельности обучающихся. Отчет должен содержать следующие разделы: 1. Наименование работы. 2. Цель работы. 3. Результаты выполненных заданий: - Скриншоты пошагового выполнения задания. 5. Вывод. |