Основные определения и сокращения 4
Введение 6
1. Обзорно-аналитическая 10
1.1 Обзор аналогов 10
1.2 Описание методов решения 12
1.3 Формирование требований к системе 14
1.3.1 Запуск системы из IDE 15
1.3.2 Запуск системы на сервере сборки 15
1.3.3 Гибкая настройка системы 15
1.3.4 Работа на основе моделей сервиса 16
1.3.5 Исключение лишнего кода 16
1.3.6 Автоматический запуск тестов 16
1.3.7 Отчет о пройденных тестах 16
2. Архитектурно-технологическая 18
2.1 Технологии 18
2.2 Архитектура системы 21
2.2.1 Основной управляющий Mojo 21
2.2.2 Конфигурации системы 22
2.2.3 Сервисный слой 23
2.2.4 Слой repository 25
2.2.5 Тестовый слой 26
2.3 Шаблон CRUD-тестов 26
3. Реализация 30
3.1 Жизненный цикл системы 30
3.2 Реализация функционала 32
3.3 Конфигурация системы 36
4. Тестирование и анализ результатов 40
4.1 Задачи тестирования 40
4.2 Тестирование 40
4.3 Анализ результатов 42
Заключение 44
Список источников 45
Приложения должны быть в работе, но в данный момент отсутствуют
Индустрия информационных технологий развивается огромными темпами. Ежедневно появляется большое количество новых или обновленных продуктов данной сферы. Компании тратят на это много денег и времени. Кроме того, такая работа обусловлена тяжелым умственным трудом. Зачастую в погоне за лидерством на рынке, когда результат нужен здесь и сейчас, приходится выполнять работу в сжатые сроки. В связи с этим в ходе работы возникают ошибки, исправление которых обходится дорого.
Ошибки возникают различного характера. Однако чаще всего это ошибки в программном коде. И чем больше разрабатываемая система, тем выше вероятность появления недостатков в программе. На обнаружение и исправление проблем необходимо выделять дополнительное время, которое прямо пропорционально величине проекта.
Наличие тестового покрытия решает проблему быстрого обнаружения ошибок в коде.
В больших системах тестирование базовой функциональности требует много времени за счет огромного количества сущностей. Поэтому при быстрой итеративной разработке компании часто отказываются от написания тестов, аргументируя это:
— Недостатком времени,
— Недостатком человеческих ресурсов,
— Недостатком средств,
— Наличием более приоритетных задач.
В свою очередь, это влечет игнорирование очевидной пользы тестирования CRUD функциональности:
1. Тесты помогают быстро обнаружить проблемы в базовых функциональностях.
На ручное тестирование с попытками отлова ошибки с помощью «дебагера», а случае обнаружения причины проблемы ее решение, последующие сборки и развертывания проекта для проверки работоспособности программы требуют много времени. Время, затрачиваемое на проделывание процедуры поиска ошибки в коде, в разы больше времени, необходимого для запуска нескольких тестов.
2. Отсутствие тестов повышает риск возникновения ошибок при изменении сущностей, что сказывается на качестве конечного продукта.
Работа над проектами идет годами, не смотря на постоянную поддержку проектов, часто заказчиками в них вносятся изменения. Многие обновления системы требуют кардинальных перемен, в том числе и на уровне базы данных: вносятся дополнительные сущности, связи по ним. В свою очередь это влечет и изменения в моделях разрабатываемого сервиса. И так как проект постоянно растет, растет и спектр возможных ошибок, возникновение которых следует предотвращать. При рутинном ритме разработки проверку работы базовой функциональности откладывают. Когда решение общей задачи уже на финальной стадии, приступают к проверке работы программы. И под слоями изменений заметить мелкую неточность, допущенную в процессе изменения сущностей проекта, представляется более сложным. Увеличивается риск появления скрытой ошибки, обнаружение которой возможно произойдет уже в «релизе».
3. Выбор в пользу скорости и дешевизны себя не оправдывает.
Вопрос о необходимости тестового покрытия часто возникает на поздних этапах разработки, там самым становясь еще более ресурсозатратными. Однако данная проблема так же появляется из-за неправильного подхода к процессу разработки. Существует полезная практика представленная моделью «плати по ходу дела»[1]. Согласно которой следует писать unit-тесты с самого начала, следом за внедрением какой-либо новой функциональности. Таким образом, исключается возможность появления так называемого «нервного периода», когда разработчики будут пытаться написать много тестов покрывающих большое число функциональностей сразу. Что и влечет за собой большие траты ресурсов.
Проблема покрытия функциональностей тестами в процессе разработки представлена наглядно. Несомненно, можно воспользоваться моделью упомянутой автором выше. Однако в случае, если разработка ведется давно, переход к другому подходу в работе над проектом также может обойтись дорого.
Следовательно, решением поставленной проблемы стало бы использование инструмента, решающего задачу внедрения тестового покрытия, отвечающего за проверку работоспособности программного продукта.
Инструмент, генерирующий тесты, решает сразу несколько проблем, которые встают перед разработчиками. Программистам не нужно будет тратить время на написание тестов, а значит, команда не будет испытывать нехватку в человеческих ресурсах в решении текущий задач, и исключается необходимость траты дополнительных средств на написание тестов. Понадобится немного времени на первичную установку и настройку инструмента для проекта.
Однако генерация всех тестов в проекте выглядит утопической идеей. Поскольку не представляется возможным сгенерировать полноценные тесты для функциональностей, решающих сложные задачи, реализующиеся с помощью нестандартных алгоритмических решений. Но в каждом проекте есть такой слой, который представляется базовыми или CRUD функциональностями.
CRUD функциональности - это такие базовые функции, которые позволяют работать с персистентными хранилищами данных. Данные функции реализуют создание, обновление и удаление сущности в базе данных, а также ее чтение из хранилища .
Исходя из вышеописанной проблемы, автор поставил перед собой цель реализовать такой инструмент, который представляет собой систему автоматической генерации unit-тестов на основе моделей сервиса для обеспечения покрытия тестами CRUD функциональности.
В результате выполнения дипломной работы была спроектирована и создана система автоматической генерации unit-тестов на основе моделей сервиса для обеспечения покрытия тестами CRUD функциональностей в виде Maven плагина CRUD Test Generator.
В процессе выполнения дипломной работы были успешно решены следующие поставленные задачи:
— Проведен обзор существующих решений и способов реализации, и на основе этого выбрано решение поставленной задачи;
— Создан шаблон написания CRUD-тестов;
— Спроектирована система, генерирующая unit-тесты оптимальным образом;
— Создан плагин, удовлетворяющий требованиям и решающий поставленную проблему;
— Проведено тестирование конечного продукта и оценка полученных результатов.
Поскольку в процессе реализации системы возникла проблема привязки плагина к конкретной базе данных, в дальнейшем планируется решение данной проблемы.
