9. Тестирование - gilgenbergg/green_office GitHub Wiki

Модульное тестирование производилось с использованием библиотеки JUnit автоматически. Тесты покрывают логику бизнес процессов и различаются лишь на уровне работы с данными - с репозиторием, построенным на основе примитивных коллекций и мапперами для работы с БД. Отличие можно проследить на ветках master и “with-db”. Тесты расположены в директории /green_office/project/src/tests/ и включают в себя прохождение стадий бизнес процессов, а также в случае с репозиториями дополнительные “мелкие” модульные тесты пользовательских операций.

• Тест ClientFirstRequestTest() - проверяет корректность логики работы над первичной заявкой, начиная от ее создания клиентом, и заканчивая получением фидбека.
  Включает в себя несколько “ассертов”, уточняющих последовательную действительную смену статусов заявки в ходе ее перехода от пользователя к пользователю. Оставляется положительный фидбек.
• Тест ClientPlannedRequestTest() - проверяет корректность обработки плановой заявки. Оставляется отрицательный фидбек.
• Тест void PurchaseRequestTest() - данный тест включает в себя проверку этапов создания заявки на закупку и непосредственно ее осуществления, т.к. процессы и данные, обмениваемыми между ними связаны, разделять их на отдельные мелкие тесты было нецелесообразно. На этапе работы с репозиториями в качестве слоя хранения данных бизнес-логика также была подвергнута более тщательному тестированию для отладки в соответствии с пользовательской ролью.
  Прохождение тестов:
  
  
  Прохождение тестов при работе с базой данных посредством реализованных мапперов:
  
  Функциональное тестирование производилось через пользовательский интерфейс вручную. Были пройдены сценарии бизнес-процессов, обработаны ошибочные ситуации. Ниже приведены результаты обработок ошибок пользовательского ввода:
  Попытка зарегистрироваться с уже занятым логином:
  
  Попытка закончить регистрацию с незаполненными полями (аналогичное сообщение появляется для каждого из полей):
  
  Попытка закончить регистрацию с невыбранной ролью:
  
  Попытка авторизоваться с невалидными входными данными:
  
  Попытка авторизоваться без заполненного поля логина:
  
  Попытка авторизоваться без пароля:
  
  Попытка создать заявку типа “planned” без идентификатора имеющегося в базе растения:
  
  Попытка создать растение без владельца:
  
  Попытка создать растение без названия:
  
  Попытка войти в редактор клиентской заявки без указания идентификатора заявки:
  
  Попытка внести в список покупок отсутствующий в каталоге магазина-партнера товар (на основе обращения по названию введенного ресурса к внешнему сервису):
  
  Попытка создать заявку с незаполненными полями:
  
  Попытка перейти в режим “садоводства” без указания идентификатора конкретной заявки:
  
  Попытка перейти в режим проверки закупки без указания идентификатора конкретной заявки:
  
  Попытка закончить редактирование заявки по итогу выезда без указания даты следующей инспекции:
  
  Тестирование workflow системы:
  Клиент создает первичную заявку, выбрав соответствующий тип и нажав кнопку “done”.
  
  По итогу мы видим в списке заявок созданный элемент с присвоенным на уровне БД идентификатором:
  
  Администратор, которому система определила в работу данную заявку автоматически увидит ее в списке списке своих клиентских заявок в статусе “NewOne”:
  
  Администратора создает новую карточку растения (известно от клиента заранее), закрепляя ее за конкретным клиентом после нажатия на кнопку “Add Plant”:
  
  Созданное растение необходимо привязать к ранее созданной заявке и выбрать садовника, который будет проводить работы. После чего переводит заявку в статус “inProgress”:
  
  Для первичной заявки необходимо произвести закупку:
  
  
  Ответственный за данное растение садовник видит в своем личном кабинете соответствующие заявки:
  Перейдя в CheckMaster 520й заявки на закупку, садовник видит список необходимых для данного растения ресурсов и тех, которые закуплены в рамках данной закупки:
  
  После чего он может или одобрить или отклонить закупку. В данном случае заявка будет возвращена в статус “InProgress”, т.к. закупка неполная. Когда администратор создает новую заявку на закупку, она будет автоматически закреплена системой за садовником заново, соответственно, проверяющий сотрудник может измениться. В случае корректной закупки статус заявки на закупку будет переведен в “approved”, а связанная с ней клиентская заявка будет переведена из статуса “inCheck” в статус “gardening” администратором, после чего садовник будет понимать, что возможно проведение инспекции:
  
  По итогу всех закупок, ресурсы синхронизируются:
  
  После одобрения заявки на закупку статус заявки изменяется на соответствующий:
  
  Теперь ответственный за выполнение инспекции садовник совершает вызов и редактирует дату следующей инспекции с помощью GardenMaster, после чего статус заявки изменяется на “done”:
  
  
  Клиент на каждом этапе может следить за ходом работы над заявкой, а также имеет доступ к информации о растении:
  
  *Весь процесс для заявки типа “planned” аналогичен с той разницей, что происходит привязка к уже имеющемуся растению в базе, создание новой карточки не требуется.