Покрытие Jacoco и параметры по умолчанию Kotlin

У меня есть следующий конструктор:

open class IPFS @JvmOverloads constructor(protected val base_url: String = "http://127.0.0.1:5001/api/v0/", protected val okHttpClient: OkHttpClient = OkHttpClient.Builder().build(), protected val moshi: Moshi = Moshi.Builder().build()) { 

Теперь при измерении покрытия я всегда получаю промахи, когда используются значения по умолчанию. Единственный выход, который я могу себе представить, – написать несколько тестов в java, которые используют другие конструкторы, – но я хотел бы остаться в чистом котлине – есть ли способ сделать это?

введите описание изображения здесь

Обновление: я использую такие конструкторы, как IPFS () в своих тестах, но я думаю, что в сгенерированном байт-коде Java это преобразуется в конструктор со всеми тремя параметрами – и это единственное, что якоко видит

Поскольку вы используете аннотацию @JvmOverloads , компилятор будет генерировать 3 перегруженных конструктора. Эта аннотация в основном используется для того, чтобы опустить параметры в простой Java.

 @Target([AnnotationTarget.FUNCTION, AnnotationTarget.CONSTRUCTOR]) annotation class JvmOverloads 

Поручает компилятору Kotlin генерировать перегрузки для этой функции, которые заменяют значения параметров по умолчанию.

Если метод имеет N параметров, а M из которых имеет значения по умолчанию, генерируются M перегрузки: первый принимает параметры N-1 (все, кроме последнего, которое принимает значение по умолчанию), второе принимает параметры N-2, и поэтому на.

При вызове конструктора с любым количеством параметров в Kotlin будет вызываться конструктор 3-параметров по умолчанию – где значения по умолчанию используются для опущенных параметров.
Таким образом, имеет смысл, что Jacoco не отмечает перегрузки как покрытые: они не являются.

Как и @voddan, эти перегрузки генерируются и гарантируются корректно. Не имеет смысла тестировать их отдельно.

Если вам действительно нужен полный охват, удалите аннотацию @JvmOverloads . Это должно предотвратить создание дополнительных перегрузок.

Если вы не можете удалить аннотацию, потому что вы будете вызывать перегруженный конструктор из Java, тогда наличие набора тестов Java, который их охватывает, имеет смысл в конце концов: это сценарий реального мира, который вы хотите охватить.

Вы уверены, что вам нужен 100% -ый охват этих конструкторов? Эти конструкторы автоматически генерируются компилятором, что гарантирует их правильность (в большей степени, чем покрытие кода).

IMO достаточно проверить конструктор со всеми настраиваемыми параметрами. Дополнительный тест для всех параметров по умолчанию может охватывать вычисление значений по умолчанию.

В целом, тестирование автоматического сгенерированного кода может быть не лучшей идеей.