Класс Test Config с несколькими закрытыми конечными полями

Как бы вы посоветовали «исправить» этот класс для лучшего тестирования?

public class Config {
    private final ComplexA complexA;
    private final ComplexB complexB;
    (...)

    Config(String[] args) {
         complexA = privateMethodCalculatesA(args);
         complexB = privateMethodCalculatesB(args);
         (...)
    }
}

Теперь все методы, которые вычисляют complexA/B/..., предназначены для быстрого сбоя, если пользователь вставляет несуществующие или неправильные параметры с System.exit. Проблема здесь в том, что Config искажается методами, которые следует тестировать изолированно.

Тем не менее, одни и те же методы не должны публиковаться, а результат следует кэшировать, поскольку расчет может быть дорогостоящим.

Просто попасть в цель и объявить указанные методы static protected и протестировать их по отдельности?

Как правильно это сделать?

См. stackoverflow.com/questions/25594090/…

user7294900 07.12.2018 18:47

@ user7294900 спасибо! Это полезно и уже используется в других тестах, но в этом конкретном сценарии при инициализации Config я бы издевался над множеством частных методов, просто чтобы подавить их. А новые переменные потребуют больше частных методов в конструкторе, что сделает недействительными предыдущие тесты. Это действительно разумнее, чем использовать эти методы с static protected? Спасибо за ваше время.

Frankie 07.12.2018 18:56

Я не уверен, что изменить код для теста лучше, но это зависит от

user7294900 07.12.2018 19:01
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
3
37
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Рассмотрите возможность разделения ComplexA, ComplexB и т. д. На их собственные классы. Это решает проблему независимого тестирования. Тогда вы столкнетесь с проблемой собрать по кусочкам в единое целое. Скорее всего, для этой проблемы вы предпочтете композицию, а не наследование; но любой подход может работать.

Да, думаю, это исправит. Спасибо! Не знаю, почему я сопротивлялся самому прямому пути.

Frankie 13.12.2018 01:17

Другие вопросы по теме