а вот наследовать тесты - плохая практика.
Вот здесь я не понял Вас немного. Каждый методу меня это этап бизнес процесса. Вот cardFill - это заполнение карточки заявления. В итоге я хочу на одной ветке БП создать этот метод (так как я и сделал в классе FirstBP_OrgCreating) , а дальше наследовать все классы от этого класса, и просто вызывать этот метод. Я не могу понять чем это чревато?
1) Ваши классы нарушают SRP в чистом виде.
Они не выполняют одну задачу, а выполняют две - проверяют какой-то функционал и создают драйвер.
Вам нужно вынести всю логику по работе с драйвером в базовый класс для всех тестов. Всё создание драйвера и его уничтожение будет описано в одном месте.
От него и надо будет наследовать классы тестов.
В идеале это должна быть фабрика по созданию нужного драйвера.
В классах тестов не должно быть никакого упоминания о драйвере!
Сейчас у вас создание драйвера, во-первых, имеет хардкод в жесткий диск (это вообще жесть полная), во-вторых - предусмотрено создание только хромдрайвера.
И, опять же, дублирование кода создания драйвера, при этом один класс наследует другой... выглядит странным.
Чем всё это чревато? А тем, что если у вас поменяется что-то в создании драйвера, например, вам будет нужен не хром, а лиса - вам придётся это менять во всех местах.
Эту проблему вообще надо решать другим путём, конечно, это просто как пример.
2) Сейчас у вас заполнение карточки является по сути не тестом, а precondition шагом.
В той реализации, что у вас есть - у вас все тесты будут зависеть по факту от одного теста. Зависимые тесты - это очень плохо. Если ваш первый тест не будет работать - все остальные тоже не будут работать из-за того, что они не могут выполнить precondition шаг.
В идеале, нужно уходить от такого рода шагов. Например, путём создания другого precondition шага, который будет в БД приложения записывать нужные данные, а тест уже будет их использовать.
Таким образом, если создание precondition шага в интерфейсе не будет работать - вы сможете проверить другой функционал, минуя его.
А в отдельном одном тесте уже проверять непосредственно cardFill через интерфейс.
Действия на страницах надо выносить не в базовый класс, а следовать PageObject паттерну, и выносить это в отдельные методы на конкретном pageobject'е. А в самих PageObject применять композицию для избежания дублирования кода.
Допустим, есть общее меню для всех страниц - его нужно выносить в отдельный класс (я их называю блоками) и используя композицию вносить его во все pageobject, где он присутствует.
Таким образом, элементы описанные в этом блоке - будут описаны в одном месте, и при их изменении вам нужно будет исправить их только в одном месте, а не на всех страницах.
Общее видение PageObject:
У вас есть страница Cards.
Создаёте класс Cards, в нём создаете мелкие методы, которые делают что-то на этой странице.
Потом, если вас это не устраивает - делаете там же общий метод cardFill, который содержит в себе вызовы мелких методов, а не дублирует их логику.
А в тесте уже используете этот класс и методы из него. Здесь не нужно наследование.