php - tutorial - Pruebas unitarias: preguntas para principiantes

pruebas unitarias php (4)

(No del todo en el mismo orden que sus preguntas)

Si el conjunto de pruebas completo no tarda demasiado, siempre debe ejecutarlo completo. A menudo no sabes qué efectos secundarios pueden resultar de los cambios exactamente.
Si puede combinar las pruebas de velocidad con su herramienta de prueba de unidad favorita, debe hacerlo. Esto le brinda información adicional sobre la calidad de sus cambios. Pero solo haz esto para partes de tu código que sean críticas en el tiempo.
De Wikipedia: "Una unidad es la parte más pequeña comprobable de una aplicación".

Finalmente estoy empezando con las pruebas unitarias, sabiendo que debería hacerlo por un tiempo, pero tengo algunas preguntas:

¿Debo o no debo volver a evaluar las clases para padres al evaluar a los niños si no se han sobrescrito los métodos?
Conceptualmente, ¿cómo se prueba la parte enviada de un formulario? Estoy usando PHP. ( Editar : La razón por la que pregunto esto es porque tengo una clase de formulario de alto nivel que genera un formulario, lo valida, lo filtra y genera cualquier mensaje de error tomando una matriz similar a JSON como entrada y delegando a una variedad de clases más pequeñas Sin embargo, no puedo probar los errores, etc. sin enviar el formulario. Editar : parece que podría ser una respuesta.)
Si tiene un parámetro opcional en un método, ¿debería escribir una prueba para ambos cuando están presentes y cuando no?
¿Deberían las pruebas unitarias combinarse de algún modo con el tiempo de ejecución del código de prueba o deberían permanecer completamente separadas?
¿Hay alguna razón válida para no ejecutar su conjunto de pruebas completo cada vez?
Así que estoy obteniendo mi terminología correcta, ¿a qué se refiere la unidad en las pruebas unitarias? ¿La clase está siendo probada? ¿El método? ¿El parámetro? ¿Algo más?

Responderé a los que pueda.

¿Debo o no debo volver a evaluar las clases para padres al evaluar a los niños si no se han sobrescrito los métodos?

Debería probar completamente al padre, luego probar solo qué cambios hay en el niño.

Si tiene un parámetro opcional en un método, ¿debería escribir una prueba para ambos cuando están presentes y cuando no?

Sí, pruebe cualquier cosa que cause un cambio en el comportamiento.

¿Deberían las pruebas unitarias combinarse de algún modo con el tiempo de ejecución del código de prueba o deberían permanecer completamente separadas?

Deben permanecer separados. La prueba unitaria es para probar que un método hace lo que se supone que debe hacer. Debe probar el tiempo de ejecución del código en un nivel de sistema, luego descomponerlo para encontrar cuellos de botella. Probar el rendimiento de cada unidad individual solo conducirá a una optimización prematura.

¿Hay alguna razón válida para no ejecutar su conjunto de pruebas completo cada vez?

Si el conjunto de pruebas es enorme y demora mucho tiempo, es posible que solo desee ejecutar un subconjunto mientras aún está en desarrollo . Debería ejecutar todo el paquete cuando (piense que) haya terminado para asegurarse de que no haya roto nada más.

Así que estoy obteniendo mi terminología correcta, ¿a qué se refiere la unidad en las pruebas unitarias? ¿La clase está siendo probada? ¿El método? ¿El parámetro? ¿Algo más?

"Unidad" se refiere al método que se prueba. Esta es la unidad más pequeña a la que tiene sentido dividir el software. Un método para la clase A podría usar la clase B, pero a cualquier prueba que escriba para ese método no debería importarle. Solo prueba ese método.

Respuestas a preguntas en orden:

Si las clases para padres ya se han probado, evite la duplicación y simplemente pruebe los aspectos nuevos del niño o cualquier aspecto que el niño haya cambiado.
No estoy seguro - he hecho muy poco PHP.
Sí => prueba todos los aspectos del método.
Podría tener algunas pruebas unitarias que evalúen el rendimiento, pero se centrarían en el rendimiento, ya que otras podrían centrarse en probar la funcionalidad. No mezcle ambos en la misma prueba.
Lo ideal es que los ejecutes cada vez y con frecuencia. A veces, si el tiempo de ejecución es enorme, puede considerar refaccionarlos en suites más pequeñas y luego ejecutar solo las suites afectadas cuando algo cambie, pero aún así hacer todo periódicamente.

Test parent, test child; si el niño no anula el método principal, no es necesario volver a probarlo.
No estoy seguro de entender el segundo. Puede usar Selenium para automatizar la prueba de un formulario. ¿Es eso lo que quieres decir?
Las pruebas deben incluir el "camino feliz" y todos los casos extremos. Si tiene un parámetro opcional, escriba pruebas para mostrar el funcionamiento correcto con el valor presente y ausente.
Pruebas unitarias, pruebas de integración, pruebas de aceptación, pruebas de carga son todas ideas diferentes que pueden tener cierta superposición.
Apuesto a que hay razones válidas, pero si está haciendo compilaciones automáticas que ejecutan el conjunto de pruebas de forma automática, ¿por qué no debería ejecutarlas? Tal vez vienen a la mente tiempos largos, pero esa es la única razón por la que puedo pensar. El valor es ver que todos continúan pasando, y que los cambios que ha realizado no han roto nada.
Prueba de unidad para mí significa la clase que está probando, que puede tener varios métodos. Los asocio con clases, no formularios. Las formas me dicen UI y pruebas de integración.