2010-09-28 10 views
8

en nuestra aplicación, esperamos que la entrada del usuario dentro de un Thread de la siguiente manera:escritura de datos en System.in

BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); 

quiero pasar esa parte en mi unidad de prueba para que pueda reanudar el hilo para ejecutar la resto del código. ¿Cómo puedo escribir algo en System.in desde junit?

+1

no pensé que podía, pero al parecer se puede acuerdo con Justin. Sin embargo, ¿no sería mejor refactorizar el código probado para obtener el inputtream insertado desde afuera? –

+0

@Bart, si está probando una aplicación que recibe información de 'System.in', eventualmente querrá probar el módulo que toma los datos de' System.in'. – jjnguy

+2

@Justin ¿No es esta prueba Java y no su código? Si haces InputStream inyectado todavía estás probando todo tu código y dependiendo de Java para proporcionar un System.in correcto. –

Respuesta

20

Lo que quiere hacer es usar el método setIn() de System. Esto le permitirá pasar datos al System.in desde junit.

+0

Esto funciona cuando ejecuto las pruebas de JUnit de forma individual, pero cuando ejecuto toda la clase, mi programa parece estancarse en los puntos donde el setIn() debería estar funcionando. ¿Alguien más tiene este problema y, de ser así, alguna idea sobre cómo solucionarlo? – decal

+0

@decal su problema puede haber sido la configuración incorrecta() y tearDown() modificando esos valores System.in() y System.out(). Hay otras referencias a ese problema en otros lugares de SE. Si alguien más ve este comentario, buscaré y reemplazaré. – Crowie

9

Reemplazar por la duración de la prueba:

String data = "the text you want to send"; 
InputStream testInput = new ByteArrayInputStream(data.getBytes("UTF-8")); 
InputStream old = System.in; 
try { 
    System.setIn(testInput); 

    ... 
} finally { 
    System.setIn(old); 
} 
+0

Pequeño detalle: dado que el bufferreder está construido sin un juego de caracteres, ¿no debería llamar también a 'getBytes()' sin un juego de caracteres (o, por supuesto, agregar un charset al bufferreder) –

5

En lugar de las sugerencias anteriores (edición: Me di cuenta de que Bart dejó esta idea en un comentario así), sugeriría hacer su clase más unidad comprobable haciendo que la clase acepte la fuente de entrada como un parámetro constructor o similar (inyecte la dependencia). Una clase no debería estar tan acoplada a System.in de todos modos.

Si su clase se construye a partir de un lector, que sólo puede hacer esto:

class SomeUnit { 
    private final BufferedReader br; 
    public SomeUnit(Reader r) { 
     br = new BufferedReader(r); 
    } 
    //... 
} 

//in your real code: 
SomeUnit unit = new SomeUnit(new InputStreamReader(System.in)); 

//in your JUnit test (e.g.): 
SomeUnit unit = new SomeUnit(new StringReader("here's the input\nline 2")); 
Cuestiones relacionadas