¿Cuántas pruebas por método?
Bueno, el máximo teórico y poco práctico es la complejidad de N-Path (suponga que todas las pruebas cubren diferentes formas a través del código;)). ¡El mínimo es UNO! Según el método público , es decir, no prueba los detalles de implementación, solo los comportamientos externos de una clase (valores de retorno y llamadas a otros objetos).
Usted cita:
* Y la idea de probar cada uno de sus métodos con su propio método de prueba (en una relación 1-1) será ridícula. * *
y luego preguntar:
Entonces, si crear una prueba para cada método es 'risible', ¿cómo / cuándo elige para qué escribe las pruebas?
Pero creo que entendiste mal al autor aquí:
La idea de tener one test methodper one method in the class to testes lo que el autor llama "risible".
(Al menos para mí) No se trata de 'menos' sino de 'más'
Así que déjame reformular como lo entendí:
Y la idea de probar cada uno de sus métodos con SOLO UN MÉTODO (su propio método de prueba en una relación 1-1) será ridícula.
Para cotizar su cotización nuevamente:
Cuando te das cuenta de que se trata de especificar el comportamiento y no escribir pruebas, tu punto de vista cambia.
Cuando practicas TDD no piensas :
Tengo un método calculateX($a, $b);y necesita una prueba testCalculcateXque pruebe TODO sobre el método.
Lo que TDD le dice es que piense en lo que DEBE hacer su código :
Necesito calcular el mayor de dos valores (¡ primer caso de prueba! ) Pero si $ a es menor que cero, entonces debería producir un error (¡ segundo caso de prueba! ) Y si $ b es menor que cero, debería ... ( tercer caso de prueba! ) y así sucesivamente.
Desea probar comportamientos, no solo métodos únicos sin contexto.
De esa manera, obtienes un conjunto de pruebas que es documentación para tu código y REALMENTE explica lo que se espera que haga, tal vez incluso por qué :)
¿Cómo haces para decidir para qué parte de tu código creas pruebas unitarias?
Bueno, todo lo que termina en el repositorio o en cualquier lugar cerca de la producción necesita una prueba. No creo que el autor de sus citas esté en desacuerdo con eso, como intenté decir en lo anterior.
Si no tiene una prueba, es mucho más difícil (más costoso) cambiar el código, especialmente si no es usted quien realiza el cambio.
TDD es una forma de asegurarse de que tiene pruebas para TODO, pero siempre y cuando las escriba, está bien. Por lo general, escribirlos el mismo día ayuda, ya que no lo hará más tarde, ¿verdad? :)
Respuesta a comentarios:
No se puede probar una cantidad decente de métodos dentro de un contexto particular porque dependen o dependen de otros métodos
Bueno, hay tres cosas que esos métodos pueden llamar:
Métodos públicos de otras clases.
Podemos burlarnos de otras clases, por lo que hemos definido el estado allí. Tenemos el control del contexto para que no haya un problema allí.
* Métodos protegidos o privados en el mismo *
Cualquier cosa que no sea parte de la API pública de una clase no se prueba directamente, por lo general.
Desea probar el comportamiento y no la implementación, y si una clase hace todo, funciona en un gran método público o en muchos métodos protegidos más pequeños que se llaman es la implementación . Desea CAMBIAR esos métodos protegidos SIN tocar sus pruebas. ¡Porque sus pruebas se romperán si su código cambia, cambie el comportamiento! Para eso están tus exámenes, para decirte cuando rompes algo :)
Métodos públicos en la misma clase.
Eso no sucede muy a menudo, ¿verdad? Y si le gusta en el siguiente ejemplo, hay algunas maneras de manejar esto:
$stuff = new Stuff();
$stuff->setBla(12);
$stuff->setFoo(14);
$stuff->execute();
Que los establecedores existan y no formen parte de la firma del método de ejecución es otro tema;)
Lo que podemos probar aquí es si las ejecuciones explotan cuando establecemos los valores incorrectos. Eso setBlaarroja una excepción cuando pasa una cadena se puede probar por separado, pero si queremos probar que esos dos valores permitidos (12 y 14) no funcionan JUNTOS (por cualquier razón) que ese es un caso de prueba.
Si desea un conjunto de pruebas "bueno" puede, en php, quizás (!) Agregar una @covers Stuff::executeanotación para asegurarse de que solo genera cobertura de código para este método y las otras cosas que solo se configuran deben probarse por separado (nuevamente, si quieres eso).
Entonces, el punto es: tal vez primero necesite crear algo del mundo circundante, pero debería poder escribir casos de prueba significativos que generalmente solo abarcan una o tal vez dos funciones reales (los setters no cuentan aquí). El resto se puede burlar del éter o probar primero y luego confiar en él (ver @depends)
* Nota: La pregunta se migró de SO e inicialmente era sobre PHP / PHPUnit, por eso el código de muestra y las referencias son del mundo php, creo que esto también es aplicable a otros idiomas, ya que phpunit no difiere mucho de otros xUnit marcos de prueba.