Тестирование метода путем переопределения закрытой переменной класса в качестве начального шага перед рефакторингом - PullRequest
Новая
       14

Тестирование метода путем переопределения закрытой переменной класса в качестве начального шага перед рефакторингом

0 голосов
/ 04 мая 2018

Каков наилучший способ написания модульного теста для метода, такого как my setProperties (см. Ниже), в котором используется переменная конфигурации private (config). Я пытался, но не смог переопределить его, используя отражение и Макито, но безуспешно. Я понимаю, что лучше всего изменить дизайн, чтобы упростить тестирование кода, но я хочу создать несколько модульных тестов до Рефакторинг кода. 

public class MainClass {
    private final java.lang.String config = "app.properties";

    public TestClass() {
        try {
            setProperties();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public void setProperties() throws Exception {
        try {
            InputStream input = new BufferedInputStream(new FileInputStream(config));
            ..
            ..
        } catch (Exception exception) {
            throw exception;
        }
    }
}

Ответы [ 3 ]

0 голосов
/ 04 мая 2018

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

public class PropertyUtil {

        private static Properties prop;

        private static Logger logger = Logger.getLogger(PropertyUtil.class);

        private PropertyUtil() {

        }

        public void setProperty() {
            String filePath = System.getenv("JAVA_HOME") + "/lib" + "/my_file.properties";
            prop = new Properties();

            try (InputStream input = new FileInputStream(filePath)) {
                prop.load(input);
            } catch (IOException ex) {
                logger.error("Error while reading property file " + ex);
            }
        }

        public static String getProperty(String key) {
            if (prop.containsKey(key)) {
                return prop.getProperty(key);
            } else {
                return null;
            }
        }

        public static <T> T getProperty(String key, Class<T> claz) {

            if (claz.getName().equals(Integer.class.getName())) {
                return claz.cast(Integer.parseInt(prop.getProperty(key)));
            }
            if (claz.getName().equals(Long.class.getName())) {
                return claz.cast(Long.parseLong(prop.getProperty(key)));
            }
            if (claz.getName().equals(Boolean.class.getName())) {
                return claz.cast(Boolean.parseBoolean(prop.getProperty(key)));
            }
            if (claz.getName().equals(Double.class.getName())) {
                return claz.cast(Double.parseDouble(prop.getProperty(key)));
            }
            if (claz.getName().equals(String.class.getName())) {
                return claz.cast(prop.getProperty(key));
            }

            return null;
        }
0 голосов
/ 04 мая 2018

Рефакторинг немного, извлекая метод с параметром, который принимает входной поток. Вызовите этот новый метод (возможно, защищенный пакетом) из старого. Написать тесты против нового метода. Тогда сделайте больше рефакторингов.

0 голосов
/ 04 мая 2018

Это признак сломанной конструкции; не кодируйте подобные вещи. А еще лучше определите, какова соответствующая ответственность за этот класс, и в порядке убывания предпочтений:

  • передать объект со свойствами конфигурации, строго типизирован
  • передать Map со свойствами конфигурации
  • передать InputStream для файла свойств

Поскольку File объекты никогда не доступны из jar, вы никогда не должны делать такие интерфейсы более специфичными, чем InputStream или Reader, чтобы вы всегда могли передавать потоки из вашего пути к классу jar.

...