В ваших вопросах (на мой взгляд) есть несколько неправильных представлений, поэтому я постараюсь ответить на них и дать ответ.
Каратэ относится к категории Java Only Framework
Карате действительно реализовано в Java, но вы пишете тесты в нейтральном для языка синтаксисе (Gherkin) - и вы обычно работаете с полезными нагрузками запросов и ответов в виде чистого JSON. А для бизнеса по тестированию веб-сервисов язык вообще не должен иметь никакого значения - если вы говорите по HTTP и JSON - и не в этом весь смысл веб-сервисов.
Можем ли мы иметь языковые расширения
И чтобы добавить к замечаниям, которые я сделал выше, вам действительно не нужны какие-либо специфичные для языка расширения. Карате на самом деле используется многими командами .NET, Python и JS - потому что все, что вам нужно, это JRE (даже не JDK) - и автономный исполняемый файл позволяет вам запускать тесты и даже генерировать CI -совместимые отчеты. Для примера демонстрационного проекта, который вы можете попробовать (через несколько минут), который будет работать кроссплатформенно, посмотрите на это: https://github.com/ptrthomas/karate-sikulix-demo
тесты могут сидеть вместе с кодом приложения
Да, тесты каратэ - это текстовые тесты, и вы можете проверить их вместе с кодом вашего сервера приложений, и многие команды делают это. Да, если это проект Java Maven или Gradle - его немного проще интегрировать в работу по сборке или настройке CI, но именно здесь начинает светить автономный CLI.
Аналогично рамкам PACT
Вы хотите сказать, что хотите просто внедрить тесты по договору с потребителем? Взгляните на этот проект: https://github.com/ptrthomas/payment-service - который, по моему скромному мнению, демонстрирует, как Каратэ делает CDC намного элегантнее и проще, чем Пакт (отказ от ответственности, я разработчик каратэ). Стоит повторить, что каратэ - это простой текст, не зависит от языка и может запускаться через кроссплатформенный CLI, который генерирует отчеты (JUnit XML), совместимые со всеми инструментами CI. Совместное использование тестов (или, если вы хотите назвать их контрактами) между командами - лучше всего делать через Git без необходимости заново изобретать колесо для совместной работы, одновременной разработки и управления версиями.