Параметры покрытия 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, которые используют другие конструкторы - но я хотел бы остаться в чистом Котлине - есть ли способ сделать это?

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

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

2 2
kotlin code-coverage jacoco

2 ответа:

Поскольку вы используете @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, который покрывает их, имеет смысл в конце концов: это реальный сценарий, который вы хотите охватить.

4

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

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

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