преобразователь класса test driven

Question

У меня есть класс, который должен преобразовывать данные из одного формата в другой (Database to LibraryType). Он выглядит так:

public LibraryType convertToLibrary(Database db, Parameters params) { 

    Preconditions.checkNotNull(db," missing database for conversion"); 
    Preconditions.checkNotNull(params, "missing parameters for conversion"); 

    LibraryType lib = basicFactory.createLibraryType(); 
    lib.setName(db.getName()); 
    ComponentType type = convertStructure(db.getStructure(),params); 

    if (type != ComponentType.EMPTY) { 
     lib.addComponent(type); 
    } 

    return lib; 
} 

ComponentType convertStructure(Structure s, Parameters params) { 

    if (!params.isStructureAllowed(s)) return ComponentType.EMPTY; 

    ComponentType comp = basicFactory.createComponentType();  
    comp.setName(s.getName()); 
    return comp; 
} 

У меня есть две проблемы с этой концепцией.

1. Метод convertStructure должен быть частным, потому что это не обязательно называть его с внешней стороны, но для целей тестирования я определил его пакет ширины, который не выглядит так красиво

2. В Параметрах (params) передаются в под-метод. На самом деле я бы использовал поле класса для того, которое можно было вставить во время конструктора, но из-за использования guice в качестве DI-framework я не могу передать эти данные в конструктор. Параметры будут меняться во время выполнения. Поэтому мне нужно передать его как параметр метода. Я могу установить его в поле класса в методе convertToLibrary, но тогда я не могу протестировать метод convertStructure.

Неужели я столкнулся с проблемой дизайна или есть какие-нибудь полезные обходные пути? Имеет ли смысл разделить его на разные классы, что звучит не так хорошо для меня, потому что я все еще чувствую, что это одна ответственность (SRP) в классе (преобразование данных)?

Спасибо за помощь

Answer 1

Ответ на вопрос 1 (и, возможно, вопрос 2):

Если вы чувствуете, что вам нужно написать тест для convertStructure(), я думаю, что это признак того, что она должна быть в его собственный класс. Тест не должен проверять меньше, чем на одну ответственность (ИМО).

Тем не менее, я не уверен, что вам нужно проверить convertStructure() в изоляции. Разве тестирование convertLibrary() недостаточно? Или, возможно, еще более крупная единица?

Мнение: У меня есть предпочтение тестирования снаружи, тестирование на высоком уровне для начала и тестирования небольших деталей, когда мне нужно. Начните тестирование поведения, как видно из пользователя вашей системы, и проверьте детали реализации только тогда, когда это необходимо. Однако не все согласны со мной.