Хорошая практика для тестирования фрагмента кода с использованием объекта

Question

Существуют ли какие-либо рекомендации (или лучшие практики), которые приводят в порядок следующее?

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

fun findProfileByPersonalInfo(personInfo: PersonalInfo): Profile? {
    localProfileRepository.findByPersonalInfo(personalInfo)?.let {
        return it
    }
    val searchParams = RemoteProfileSearchParameters()
    //... Some mapping from personalInfo to searchParams
    remoteProfileRepository.findRemoteProfile(searchParams)?.let {
        val profile = profileFactory.create(remoteProfile)
        return save(profile)
    }
    return null
}

Когда я пришел к написанию юнит-тестов для В этой функции я понял, что:

1. Легко и удобно проверить строку val profile = profileFactory.create(remoteProfile), потому что я могу смоделировать результат этого вызова и проверить отображение от remoteProfile до profile где-то еще отдельно , Имея это, если я изменю логику c сопоставления, я не сломаю свой тест для findProfileByPersonalInfo, что хорошо.
2. И наоборот, он чувствует себя не правильно и трудно поддерживать тест, если логика c отображения от personalInfo до searchParams принадлежит findProfileByPersonalInfo.

Вопросы:

1. Это нормально (почти) всегда перемещать экземпляры logi c из тестируемой функции, чтобы сделать ее более тестируемой и обслуживаемой? Несомненно, исключение составляют функции, единственной обязанностью которых является создание экземпляров объектов.
2. Не слишком ли много для создания фабрики определенного типа для каждого объекта, который попадает в описанную выше ситуацию? Кажется, что общий дизайн системы страдает из-за этого.

Любые ссылки на лучшие практики или обсуждения очень приветствуются. Большое спасибо!

Answer 1

1. Это немного шире, в общем, вы хотите, чтобы методы не делали слишком много и перемещали повторно используемые части кода в отдельный метод. Исходя из ограниченного контекста, который вы демонстрируете, в этом случае я бы наверняка переместил создание экземпляров как по соображениям тестируемости, так и по удобочитаемости. в контексте простой конструктор RemoteProfileSearchParameters(personInfo: PersonalInfo) может быть самым разумным здесь. В зависимости от сложности это может быть реорганизовано в фабричный метод или фактический фабричный объект, но обычно это не будет вашим первым переходом.