Рефакторинг проекта

1. UI

1.1. Чтобы не вводить больших изменений в структуре UI, группировку по модулям оставляем прежней (по смыслу). Описать структуру в WiKi и приложить ссылку в проект.

1.2. В части UI нужно удалить дубли оставшиеся после прошлого рефакторинга. Также структурировать PO классы (перенести локаторы в нужные классы, выделить методы в Actions, использовать PageObjectBase).

1.3. Структура PageObject: BasePageObject -> PageObject -> PageObjectActions (действия на странице). При необходимости вводятся хелперы.

1.3.1. Содержимое класса BasePageObject

1.3.1.1. Общий конструктор

1.3.1.2. Экземпляр PageObjectActions

1.4. Наименования карт оставляем прежним (наименование содержит ID формы, в случае его отсутствия размещается в соответствующем пакете с наименованием отражающим суть (именуется по смыслу)).

1.5. Провести рефакторинг в классах базовых элементов (Grid, Combobox и т.д.), удалить дубли, отладить, привести к единой структуре.

1.6. Провести рефакторинг общего класса PageObjectActions (удалить дубли, привести к единой структуре). Добавить закрытие алерта с адаптером для Красноярска.

2. API

2.1. Завершить перенос API-классов из модулей (старая реализация) в контролёры (новая реализация).

2.2. Зафиксировать структуру: Actions-классы содержат вспомогательные атомарные действия (поиск значения в результатах выполнения метода, поиск или создание сущности и проверка её существования, поиск и удаление сущности и проверка её удаления, поиск и изменение сущьности и проверка внесённых изменений). Паттерн - Builder. При необходимости реализации сложной логики она размещается в Helper-классе.

2.2.1. Содержание Action-класса

2.2.1.1. Поиск значения в результатах выполнения метода.

2.2.1.2. Поиск или создание сущности и проверка её существования.

2.2.1.3. Поиск и удаление сущности и проверка её удаления.

2.2.1.4. Поиск и изменение сущьности и проверка внесённых изменений.

3. Helpers

3.1. Выделить хелперы с базовыми действиями в структуре (Пациент, АПЛ, КВС, АРМ). Только такие хелперы можно использовать в своих хелперах. Аналогично для UI.

3.1.1. Струтура Helper классов

3.1.1.1. Базовые (не используют методы из других хелперов).

3.1.1.2. Вспомогательные (могут использовать методы из базовых хелперов).

3.2. Провести рефакторинг основных хелперов по работе с тестовыми данными (работа с пациентом, выбор АРМ, создание и удаление тестовых данных: КВС, АПЛ...) подходить индивидуально: где-то добавить атомарность и удалить дубли, где-то собрать в общий метод.

3.3. Провести рефакторинг helper-классов. Структура: Контролёр -> Действия над контролёром -> Хелпер. Для реализации логики хелперы не должны использовать методы из других хелперов, за исключением базовых действий (работа с пациентом, выбор АРМ, создание и удаление тестовых данных). Аналогично для UI.

3.4. Зафиксировать типы методов, размещаемых в хелпере. Например общие методы по созданию, изменению, проверке и удалению тестовых данных. Или частные случаи методов с большим количеством действий.

4. XML

4.1. Собрать все xml в одном месте с типовой структурой.

4.2. Удалить общие xml для запуска АТ на множестве регионов.

5. Структура проекта

5.1. Отдельные проекты в свои пакеты, чтобы было видно, что это проект Промед, а это проект Витрины или BI.

5.2. Переименовать базовые классы для автотестов добавив вконец названия класса Test, либо оставить один базовый класс для автотестов.