Плохая практика Java: добавление оператора возврата в метод исключительно для тестирования? - PullRequest
0 голосов
/ 04 февраля 2019

Является ли плохой практикой добавление оператора возврата с единственной целью тестирования метода без использования его в самом коде?

В качестве примера я тестирую метод чтения, за которым следуетсерия методов, которые в конечном итоге создают объект со свойствами, поглощенными из строк файла, в котором он читается.

Из того, что я понял, метод чтения может быть протестирован с использованием Mockito без необходимости добавления оператора возврата,Или можно проверить, вызывается ли другой метод (readPerLine), но я пока не нашел подходящей процедуры тестирования для этого.Эти два варианта могут означать, что мой общий вопрос не имеет значения, если используется правильная процедура кодирования, если да, пожалуйста, дайте мне знать.

Однако в настоящее время следующие два варианта являются наиболее простым способом проверки (часть)метод чтения:

  1. Добавьте оператор возврата, содержащий массив строк, в которых читается метод, который выполняется в конце метода.
  2. Проверьте комбинациюметод read и последующие методы, которые создают объекты путем измерения правильности свойств объектов.И путем тестирования последующих методов индивидуально.Это не является предпочтительным, поскольку двойная ошибка, 1 в методе чтения и 1 в концептуальном проекте последующих методов, может отменить во время этого тестирования, но вызвать ошибки в жизни.
  3. Изменение (чтение) метод, который возвращает массив строк, который передается последующим методам из Main.

Пример кода метода чтения, который я сейчас написал:

public void readFile(String filename) {
        FileReader reader;
        BufferedReader br;
        String line = null;
        try {       
            br = new BufferedReader(new FileReader(filename));

            while ((line = br.readLine()) != null) {
                readPerLine(line); //converts line into properties for an object.
            }  
            br.close();
        } catch (FileNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

Так что я еще не решил следующую дилемму;

  • Я знаю, что иногда вам нужно переписать свой метод, чтобы разрешить его тестирование.
  • Но я не знаю, будут ли добавляться такие функции, как операторы возврата, которые не используются в реальном кодено только для тестирования, это хорошая или плохая практика.Кроме того, если я это сделаю, я все еще не полностью протестирую метод чтения, вызов другого метода все еще не проверен.
  • Или не возникнет ли вообще эта дилемма, если я вначале применяю надлежащий этикет.

1 Ответ

0 голосов
/ 04 февраля 2019

Я бы предложил вместо добавления оператора возврата в метод для включения тестирования вместо этого переработать метод для разделения некоторых функций.

Я думаю, что проблема здесь:

readPerLine(line); //converts line into properties for an object.

Может быть, вы слишком много делаете в этом методе.Вы можете разбить это на несколько различных методов, например:

  1. Считать строку, чтобы получить массив String
  2. Выполнить преобразование строк в нужные типы данных
  3. Создайте свой объект и установите его свойства

Если вы это сделаете, вы можете проверить функциональность каждого шага и иметь тесты для каждого.Когда дело доходит до тестирования основного метода readFile(String filename), вы можете использовать Mokito для проверки того, что каждый метод вызывается с правильными параметрами

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...