Тестирующий сканер Java с фальшивым пользовательским вводом - PullRequest
0 голосов
/ 24 октября 2018

У меня есть метод static, который использует static final Scanner для получения пользовательского ввода с консоли.

При тестировании я хотел бы создать ряд тестов с различным вводом (очевидно,).Это работает нормально, если тесты выполняются индивидуально.Запуск всего класса не работает, потому что (по-видимому) Сканер уже инициализирован с вводом из предыдущего теста, который не имеет больше строк, чем требуется для первого теста.

Конкретная ошибка, которую я имеюПолучение:

java.util.NoSuchElementException: No line found

Вот некоторый код для пояснения:

public class UserInputHandler {
    public static final Scanner SCANNER = new Scanner(System.in);
}

Класс, который я пытаюсь протестировать (и несколько других), использует выше Scanner для запроса пользователя.

Мой тест:

InputStream in = new ByteArrayInputStream("test".getBytes());
System.setIn(in);
TestClass testclass = new TestClass();
testClass.method(); // Scanner is used in this method

Как заставить мои тесты работать для более чем одного экземпляра TestClass?

1 Ответ

0 голосов
/ 24 октября 2018

Реальная проблема здесь:

public class UserInputHandler {
    public static final Scanner SCANNER = new Scanner(System.in);
}

Вы заставляете этот входной сигнал поступить с System.in.Почему бы не использовать

public class UserInputHandler {
    public Scanner getScanner() {
      return new Scanner(someInputStream);

Конечно, теперь вам нужно беспокоиться о том, откуда исходит someInputStream, но вы позволили себе быть гораздо более гибким.

Ваш код на самом деле не находится на одном статическом объекте, вместо этого он делает вызов и получает, что читает из где-то .А затем в своих тестах вы просто определяете входные потоки и убедитесь, что эти входные потоки можно использовать (например, сделав это поле класса UserInputHandler, которое устанавливается при создании экземпляра этого класса.

Другими словами: реальное решение состоит в том, чтобы изменить ваш производственный код, чтобы сделать его A) более гибким и B) простым для тестирования.Вы получили это задом наперед: вы написали негибкий и сложный для тестирования код, а теперь вы пытаетесь согнуть свои тестовые примеры, чтобы они были разумными.

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

...