Основные принципы ООП, GRASP, SOLID, порождающие паттерны, структурные паттерны, mocking.
- Реализовать объектную модель корпоративной системы распределения сообщений, используя на практике отрабатываемый теоретический материал
- Покрыть полученное решение функциональными авто-тестами
Некоторая компания разрабатывает корпоративную систему распределения сообщений. Предметная область, которую компания автоматизирует, имеет сложный механизм формирования адресатов, а так же набор различных конечных точек для сообщений.
- Имеет заголовок
- Имеет тело
- Имеет уровень важности
- Имеет название
- Имеет адресатов
- В топик можно отправить сообщение, он должен передать его адресату
- В адресат можно передать сообщение
- Адресаты бывают нескольких видов
- Адресат-пользователь Передает сообщение пользователю корпоративной системы
- Адресат-мессенджер Отправляет сообщение используя сторонний мессенджер
- Адресат-дисплей Выводит сообщение на какое-либо физическое устройство отображения
- Адресат-группа Содержит в себе несколько адресатов, передаёт каждому из них полученные сообщения
- Необходимо иметь возможность фильтровать сообщения для конкретных адресатов по их уровню важности
- Необходимо иметь возможность логгировать сообщения, получаемые конкретным адресатом
- Является конечной точкой сообщения
- Пользователь может иметь некоторые атрибуты (не обязательно для контекста лабораторной)
- Должна быть возможность отправить пользователю сообщение
- Пользователь должен отслеживать полученные сообщения, и их статус (прочитано, не прочитано) (статус сообщения существует только в контексте пользователя)
- Пользователь должен иметь возможность отметить сообщение прочитанным
Отметить такое сообщение можно только в статусе не прочитано, попытка отметить прочитанное сообщение должна обрабатываться
- Является конечной точкой сообщения
- Должен иметь возможность выводить текст Для целей лабораторной можно просто выводить текст в консоль с припиской “мессенджер”
- Является конечной точкой сообщения
- Должен иметь возможность выводить текст заданного цвета
Дисплей должен держать лишь одно сообщение, поэтому перед выводом его необходимо очищать
- Должен иметь возможность очистить вывод
- Должен иметь возможность задать цвет выводимого текста
- Должен иметь возможность записать текст
- Реализация логгирования должна быть тестируемой
например, проверить вывод на консоль при вызове некоторых поведений в авто-тестах - невозможно
нужно иметь возможность реализовать в тестах mock-тип, который будет вести счётчик вызовов - Реализация мессенджера и дисплея должна быть тестируемой
- Реализация мессенджера и дисплея должна быть изолирована
Эти реализации не должны иметь явной или неявной зависимости на логику доставки сообщений, ведь они являются сторонними интеграциями
Их реализации должны находиться в отдельных папках - Вывод на дисплей должен быть реализован как вывод на консоль так и вывод в файл
Для упрощения окраски теста можно использовать сторонний NuGet пакет, в качестве примера использования можете использовать код второго воркшопа
https://github.com/riezebosch/Crayon
- При получении сообщения пользователем, оно сохраняется в статусе “не прочитано”
- При попытке отметить сообщение пользователя в статусе “не прочитано” как прочитанное, оно должно поменять свой статус
- При попытке отметить сообщение пользователя в статусе “прочитано” как прочитанное, должна вернуться ошибка
- При настроенном фильтре для адресата, отправленное сообщение, не подходящее под критерии важности - до адресата дойти не должно (в данном тесте необходимо использовать моки)
- При настроенном логгировании адресата, должен писаться лог, когда приходит сообщение (в данном тесте необходимо использовать моки)
- При отправке сообщения в месенджер, его реализация должна производить ожидаемое значение (в данном тесте необходимо использовать моки)
- Добавляются два адресата-пользователя (для одного пользователя), для одного из них настраивается фильтр важности, при попытке отправить сообщение с важностью ниже настроенной – пользователь получает значение единожды.