java-kanban-sprint7
java-kanban
Яндекс-практикум
Спринт 7
Техническое задание
Пора потренироваться! Теперь вы знаете, что без тестов нельзя проверить программу и убедиться, что всё работает именно так, как задумано. В трекере уже есть код проверки — он содержится в методах main. На основе этого кода вам предстоит написать тесты для менеджеров и задач.
Также в этом спринте вы добавите новую функциональность: приложение сможет расставлять задачи по приоритету и проверять, не пересекаются ли они по времени выполнения. Вперёд!
Добавьте JUnit в проект
Прежде чем приступать к написанию тестов, добавьте поддержку JUnit в проект. Для этого выполните в IntelliJ IDEA следующие действия.
- Откройте любой класс, например Epic.
- Нажмите Ctrl+Shift+T. В выпадающем меню выберите пункт Create test (англ. «Создать тест»). В появившемся окне нажмите кнопку OK — тест будет размещён в той же папке.
- В меню выбора теста (Testing library) выберите JUnit5, а затем нажмите кнопку Fix (англ. «Исправить»).
- Скачайте библиотеку в папку lib. Поставьте галочку около пункта Download to (англ. «Скачать в...») и нажмите кнопку OK, чтобы подтвердить создание теста.
- После этого откроется файл EpicTest. Можно переходить к написанию тестов. Проверьте, что все библиотеки загрузились в папку lib.
Покройте код тестами
Ваша цель — написать отдельный тест для каждого публичного метода: стандартный кейс его работы и граничные случаи. Потребуются следующие тесты.
-
Для расчёта статуса Epic. Граничные условия: a. Пустой список подзадач. b. Все подзадачи со статусом NEW. c. Все подзадачи со статусом DONE. d. Подзадачи со статусами NEW и DONE. e. Подзадачи со статусом IN_PROGRESS.
-
Для двух менеджеров задач InMemoryTasksManager и FileBackedTasksManager. Чтобы избежать дублирования кода, необходим базовый класс с тестами на каждый метод из интерфейса
-
abstract class TaskManagerTest. Для подзадач нужно дополнительно проверить наличие эпика, а для эпика — расчёт статуса. Для каждого метода нужно проверить его работу: a. Со стандартным поведением. b. С пустым списком задач. c. С неверным идентификатором задачи (пустой и/или несуществующий идентификатор).
-
Для HistoryManager — тесты для всех методов интерфейса. Граничные условия: a. Пустая история задач. b. Дублирование. с. Удаление из истории: начало, середина, конец.
-
Дополнительно для FileBackedTasksManager — проверка работы по сохранению и восстановлению состояния. Граничные условия: a. Пустой список задач. b. Эпик без подзадач. c. Пустой список истории.
После написания тестов ещё раз проверьте их наличие по списку. Убедитесь, что они работают.
Добавьте продолжительность и дату старта
Добавьте новые поля в задачи: duration — продолжительность задачи, оценка того, сколько времени она займёт в минутах (число); startTime — дата, когда предполагается приступить к выполнению задачи. getEndTime() — время завершения задачи, которое рассчитывается исходя из startTime и duration.
Менять сигнатуры методов интерфейса TaskManager не понадобится: при создании или обновлении задач все его методы будут принимать и возвращать объект, в который вы добавите два новых поля.
С классом Epic придётся поработать дополнительно. Продолжительность эпика — сумма продолжительности всех его подзадач. Время начала — дата старта самой ранней подзадачи, а время завершения — время окончания самой поздней из задач. Новые поля duration и startTime этого класса будут расчётные — аналогично полю статус. Для реализации getEndTime() удобно добавить поле endTime в Epic и рассчитать его вместе с другими полями.
Не забудьте также доработать опцию сохранения состояния в файл: добавьте в сериализацию новые поля.
Добавьте в тесты проверку новых полей.
Выведите список задач в порядке приоритета
Отсортируйте все задачи по приоритету — то есть по startTime. Если дата старта не задана, добавьте задачу в конец списка задач, подзадач, отсортированных по startTime. Напишите новый метод getPrioritizedTasks, возвращающий список задач и подзадач в заданном порядке.
Предполагается, что пользователь будет часто запрашивать этот список задач и подзадач, поэтому подберите подходящую структуру данных для хранения. Сложность получения должна быть уменьшена с O(n log n) до O(n).
Проверьте пересечения
Предполагается, что пользователь будет выполнять не более одной задачи за раз. Научите трекер проверять, что задачи и подзадачи не пересекаются по времени выполнения. Добавьте валидацию во время создания или изменения задач, подзадач.
Дополнительное задание*
А теперь необязательное задание для тех, кто хочет бросить себе вызов! Подумайте, какая структура данных и какой алгоритм проверки подойдут, чтобы уменьшить сложность поиска пересечений до O(1).
Не забудьте перепроверить код перед отправкой на ревью! Интересного вам программирования!