java-kanban

Яндекс-практикум

Спринт 7

Техническое задание

Пора потренироваться! Теперь вы знаете, что без тестов нельзя проверить программу и убедиться, что всё работает именно так, как задумано. В трекере уже есть код проверки — он содержится в методах main. На основе этого кода вам предстоит написать тесты для менеджеров и задач.

Также в этом спринте вы добавите новую функциональность: приложение сможет расставлять задачи по приоритету и проверять, не пересекаются ли они по времени выполнения. Вперёд!

Добавьте JUnit в проект

Прежде чем приступать к написанию тестов, добавьте поддержку JUnit в проект. Для этого выполните в IntelliJ IDEA следующие действия.

1. Откройте любой класс, например Epic.
2. Нажмите Ctrl+Shift+T. В выпадающем меню выберите пункт Create test (англ. «Создать тест»). В появившемся окне нажмите кнопку OK — тест будет размещён в той же папке.
3. В меню выбора теста (Testing library) выберите JUnit5, а затем нажмите кнопку Fix (англ. «Исправить»).
4. Скачайте библиотеку в папку lib. Поставьте галочку около пункта Download to (англ. «Скачать в...») и нажмите кнопку OK, чтобы подтвердить создание теста.
5. После этого откроется файл EpicTest. Можно переходить к написанию тестов. Проверьте, что все библиотеки загрузились в папку lib.

Покройте код тестами

Ваша цель — написать отдельный тест для каждого публичного метода: стандартный кейс его работы и граничные случаи. Потребуются следующие тесты.

1. Для расчёта статуса Epic. Граничные условия: a. Пустой список подзадач. b. Все подзадачи со статусом NEW. c. Все подзадачи со статусом DONE. d. Подзадачи со статусами NEW и DONE. e. Подзадачи со статусом IN_PROGRESS.

2. Для двух менеджеров задач InMemoryTasksManager и FileBackedTasksManager. Чтобы избежать дублирования кода, необходим базовый класс с тестами на каждый метод из интерфейса

3. abstract class TaskManagerTest. Для подзадач нужно дополнительно проверить наличие эпика, а для эпика — расчёт статуса. Для каждого метода нужно проверить его работу: a. Со стандартным поведением. b. С пустым списком задач. c. С неверным идентификатором задачи (пустой и/или несуществующий идентификатор).

4. Для HistoryManager — тесты для всех методов интерфейса. Граничные условия: a. Пустая история задач. b. Дублирование. с. Удаление из истории: начало, середина, конец.

5. Дополнительно для 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).

Не забудьте перепроверить код перед отправкой на ревью! Интересного вам программирования!