Как я могу проверить, что приложение CLI ждет ввода

Question

Это не то же самое, что и этот вопрос: JUnit: How to simulate System.in testing?, что касается насмешливого stdin.

Я хочу знать, как проверить (как в TDD), что простой метод Java с методом main ждет ввода.

Мой тест:

@Test 
public void appRunShouldWaitForInput(){ 
    long startMillis = System.currentTimeMillis(); 
    // NB obviously you'd want to run this next line in a separate thread with some sort of timeout mechanism... 
    // that's an implementation detail I've omitted for the sake of avoiding clutter! 
    App.main(null); 
    long endMillis = System.currentTimeMillis(); 
    assertThat(endMillis - startMillis).isGreaterThan(1000L); 
} 

Мой SUT main:

public static void main(String args[]) { 
    BufferedReader br = null; 
    try { 
     br = new BufferedReader(new InputStreamReader(System.in)); 
     System.out.print("Enter something : "); 
     String input = br.readLine(); 
    } catch (IOException e) { 
     e.printStackTrace(); 
    } 

... тест не пройден. Код не ждет. Но когда вы запускаете приложение в командной строке, он действительно ждет.

NB кстати я также попробовать с установкой stdin в sthg еще:

System.setIn(new ByteArrayInputStream(dummy.getBytes())); 
scanner = new Scanner(System.in); 

... это не выдержал испытание.

Answer 1

Как правило, статические методы (такие как методы main) трудно проверить. По этой причине вы почти никогда не вызываете метод main (или любой другой статический метод) из вашего тестового кода. Общий шаблон для работы вокруг этого, чтобы преобразовать это:

public class App { 
    public static void main(String args[]) { 
     BufferedReader br = null; 
     try { 
      br = new BufferedReader(new InputStreamReader(System.in)); 
      System.out.print("Enter something : "); 
      String input = br.readLine(); 
     } catch (IOException e) { 
      e.printStackTrace(); 
     } 
    } 
} 

к этому:

public class App { 
    private final InputStream input; 
    private final OutputStream output; 

    public App(InputStream input, OutputStream output) { 
     this.input = input; 
     this.output = output; 
    } 

    public static void main(String[] args) { 
     new App(System.in, System.out).start(); 
    } 

    public void start() { 
     BufferedReader br = null; 
     try { 
      br = new BufferedReader(new InputStreamReader(input)); 
      output.print("Enter something : "); 
      String nextInput = br.readLine(); 
     } catch (IOException e) { 
      e.printStackTrace(); 
     } 
    } 
} 

Теперь ваш тест становится этим:

@Test 
public void appRunShouldWaitForInput(){ 
    ByteArrayOutputStream output = new ByteArrayOutputStream(); 

    // As you have already noted, you would need to kick this off on another thread and use a blocking implementation of InputStream to test what you want to test. 
    new App(new ByteArrayInputStream(), output).start(); 

    assertThat(output.toByteArray().length, is(0)); 
} 

Ключевая идея заключается в том, что, когда ты запустите приложение «для реального», то есть с помощью метода main, он будет использовать стандартные входные и выходные потоки. Однако, когда вы запускаете его из своих тестов, он использует чисто входной/выходной поток в памяти, который вы полностью контролируете в своем тесте. ByteArrayOutputStream - всего лишь один пример, но в моем примере вы можете увидеть, что тест способен проверять фактические байты, которые были записаны в выходной поток.

Answer 2

в общем, вы не можете проверить, если ваша программа ждет, пока что-то не происходит (потому что вы не можете проверить, если он ждет навсегда)

, что обычно делается в таких случаях:

1. в вашем случае: не проверяйте его. readLine предоставляется внешней библиотекой, которая была протестирована довольно интенсивно. стоимость тестирования намного выше, чем стоимость такого теста. рефакторинг и тест вашего бизнес-кода (строковые/потоковые операции), а не инфраструктура (системный ввод)

2. в общем случае это тестирование параллельного программирования. это сложно, поэтому ppl обычно пытается найти какое-то полезное упрощение:

   1. Вы можете просто проверить, правильно ли вывод вашей программы на вход, предоставленный в тестах.
   2. для некоторых действительно сложных проблем выше техники сочетается с запуском теста в тысячу раз (и, если возможно, для принудительного переключения потоков) для обнаружения ошибок в параллельном программировании (нарушенных инвариантов)
   3. перед тем, как ваш тест предоставит дату ввода, вы можете проверить, ваша программа находится в правильном состоянии (ожидающий поток, правильные значения полей и т. д.)
   4. В худшем случае вы можете использовать задержку в тестах перед тем, как обеспечить ввод, чтобы убедиться, что ваша программа ждет и использует вход. этот метод часто используется, потому что это просто, но это вонючее и если добавить больше тестов, как, что весь ваш костюм становится медленнее