очень даже нормальная практика. Не парься )

Коллеги, подскажите, почему feign не прикладывает к DELETE запросу Headers?

@RequestLine("DELETE /consumers/{id}")

    @Headers({"Content-type: application/json", "Authorization: Bearer {token}"})

    Response deleteConsumerById(@Param("token") String token, @Param("id") String id);

такой вот запрос, а в ответ:

{"statusCode":415,"error":"{\"timestamp\":\"2020-02-26T11:19:50.690Z\",\"status\":415,\"error\":\"Unsupported Media Type\",\"message\":\"Content type '' not supported\",\"path\":\"/consumers/1\"}"}

тогда стор прог тебе не нужен.

В случае базы данных с динамическими данными? Как это все завязано с API? Есть на этот счет мысли?

не понял ))

проверь правильность хедеров в запросе

ничего не надо инициализировать по факту. То есть просто пустой конструктор new LoginPage().doSmth();

nop/noop - типа "no operation"

так я так и делаю в кажом тесте, типа
new Form()
       .selectM(m)
       .selectE(e);
new Navigation().scrollUpTill(blabla);
new Asserts().shouldBeExactTexts(“bla”);

Но получается что по сути я в кажом тесте делаю эти же самые newPage()
Вот и возник вопрос, может их нужно засунуть в бефор тест или  в testBase?

ты наследуешься?

Вам на page object мягко намекают :)

так я так и делаю в кажом тесте, типа
new Form()
       .selectM(m)
       .selectE(e);
new Navigation().scrollUpTill(blabla);
new Asserts().shouldBeExactTexts(“bla”);

Но получается что по сути я в кажом тесте делаю эти же самые newPage()
Вот и возник вопрос, может их нужно засунуть в бефор тест или  в testBase?

Если шаги повторяются - то
1) очевидно редундантное тестирование
2) если повторения не удаётся избежать - создать класс SomeSteps и переместить повторяющиеся шаги туда в метод. Затем вызывать этот метод из тестов.

да не шаги повторяются а повторяется в кажом тесте new Page1(), new Page2();