2010-06-17 19 views

Respuesta

2

Cuando leí su pregunta, lo interpreté en el sentido de que él se aseguraba de que send_data enviara la cadena/lo que sea que le pidiera. No tanto para probar el envío sino para garantizarle la tranquilidad de que el método que lo envió no estaba en blanco. burlarse, como lo has hecho, realmente no le da ese resultado.

Quizás pueda asegurarse de que su cadena no esté en blanco, o algo así. De esta forma, no está probando send_data, pero todo lo que send_data obtiene es cómo quiere que se vea.

En mi caso (lo que me llevó a esta pregunta) sería

#just use this to make sure it looks like you want it to while you are writing your 
#tests. I remove it after. make sure it's an instance variable @csv_string in my case. 
puts assigns(:csv_string) 

refute_nil assigns(:csv_string) #does the actual work. delete the puts line when done. 

Algunas personas utilizan más elegantes depurador rubí y sh! T ... su kilometraje puede variar.

+0

La prueba del controlador es sobre burlas. Si necesita algo "real", realice una prueba de integración. La solución a continuación es en realidad la "forma rspec" si quieres. – yiwen

+0

¿La prueba del controlador es sobre burlas? declaración extraña y peor, un voto hacia abajo. Cuando te burlas de eso, no estás probando nada más que el hecho de que send_data recibió un llamado y continúa haciendo su trabajo.En mi ejemplo, como dijo el OP, estamos probando que send_data realmente está haciendo su trabajo. una prueba de tranquilidad – pjammer

+0

Usa una prueba de integración para eso. las pruebas unitarias no son un lugar para probar trabajos de send_data. – yiwen

9

No debería necesitar probar el comportamiento de send_data, principalmente porque está cubierto por las propias pruebas de Rails. Además, hará que tus pruebas se ejecuten lentamente (eventualmente). Lo que debe hacer (desde mi punto de vista) es el método de código auxiliar send_data, algo así como:

controller.expects(:send_data).with("foo").returns(:success)

espero que ayude.

+4

No recomiendo esto. El código de burla que no le pertenece generalmente no es una buena idea. Si la API para 'send_data' cambia (digamos, con una actualización de Rails), no sabrá que su código está roto. –

+3

@XavierShay que es muy debatible. El código de burla y troceo que no le pertenece a menudo se considera la Única buena manera de tener pruebas unitarias reales. Sin embargo, el "flujo ascendente puede cambiar" es algo que querrá ver en las pruebas. Pero no en pruebas unitarias. Deberías tener pruebas de integración para eso. (Esto es, como su punto, solo una opinión, hay muchas) – berkes

+0

"El código de burlarse y trocear que usted no posee a menudo se considera la Única buena manera de tener pruebas unitarias reales". ¿referencia? Me gustaría leer más acerca de cómo funciona bien (a largo plazo) para las personas. Para respaldar mi propia afirmación anterior: http://www.jmock.org/oopsla2004.pdf y los principales resultados en https://www.google.com/?#safe=active&q=only+mock+types+you. + propio –

3

Puede probarlo indirectamente comprobando el valor de Content-Transfer-Encoding encabezado.

 
expect(controller.headers["Content-Transfer-Encoding"]).to eq("binary") 

o

 
controller.headers["Content-Transfer-Encoding"].should eq("binary") 
+0

controlador no está definido – nathanengineer

+0

@glochild puede ser '@ controller' funcionará para usted – prasvin

Cuestiones relacionadas