Я сегодня перещёл на 16-ю джавку. Mapstruct 1.4.2 (последний) нормально отрабатывает в обе стороны.
Могу, как говорится, держать в курсе, если будут проблемы. Пока вижу, что поддержка IDEA хромает

ok

ребятки, async profier уже опробовали, хороша штука?

Да

хорошо я выделяю в первый метод
HttpPost httpPost = new HttpPost(urlSend);
HttpEntity httpEntity = EntityBuilder.create()
       .setContentType(ContentType.create("text/csv", StandardCharsets.UTF_8))
       .setFile(fileCsv)
       .build();
httpPost.setEntity(httpEntity);
httpPost.addHeader("Authorization", "Basic " + token);
httpPost.addHeader("Accept", "application/xml");

1. Что тут можно ЮНИТ тестировать?

Отправка она же получение ответа:
CloseableHttpResponse response = client.execute(httpPost)
попадает во второй метод

2. что мне тут и как замокать для тестирования?

1) что у тебя валидно сформирован реквест
2) клиент, и проверить, что респонс от него валидно парсится, например
В дальнейшем предлагаю с такими вопросами в @javastart

Мне интересно

В Spring Boot в тестах как-то можно подложить готовый инстанс @ConfigurationProperties?

создать его бином? Через @Bean?

Там вот такое:
Cannot bind @ConfigurationProperties for bean 'blablaProperties'. Ensure that @ConstructorBinding has not been applied to regular bean

Если
public void send(FileName fileName) {
   ...
   ExecutorService executorService = Executors.newFixedThreadPool(2*Runtime.getRuntime().availableProcessors());
   ...
   executorService.execute(...);
   ...
}
как мне замокать или spy executorService
чтобы протестировать executorService.execute в этом методе send?

Не создавать executorService внутри метода, а использовать тот,который пришел. А там ты его сможешь замокать

пихать executorService параметром в метод только для того чтобы протестировать метод
неважное какое-то решение

Точнее

public void send(FileName fileName) {
   ...
   ExecutorService executorService = Executors.newFixedThreadPool(2*Runtime.getRuntime().availableProcessors());
   ...
   executorService.execute(...);
   ...
   ExecutorService executorService = Executors.newFixedThreadPool(2*Runtime.getRuntime().availableProcessors());
   ...
}

ExecutorService там все-равно дальше переопредялется логикой метода
и executorService.execute запускается в цикле снова который нужно отловить

создавать его вне метода и передавать в конструкторе, очевидно

Параметром в конструктор.И это называется Dependency Injection и это the best для тестируемости кода

во-первых это не сработает,
так как логика самого метода подразумевает переопеределение ExecutorService

public void send(FileName fileName) {
   ...
while(...) {
   ...
   executorService.execute(...);
   ...
     if (...) { ExecutorService executorService = Executors.newFixedThreadPool(2*Runtime.getRuntime().availableProcessors());
    }
}
   ...
}

типо запускаются воркеры до определенного значения, потом остановка executorService и запуск по новой чтобы избежать outOfMemory

это можно расчитать снаружи. Почему у тебя метод с названием send, решает сколько пул создать?

зачем? у тебя есть очередь в executor service, превысить количество задач ты не сможешь