unit-testing - tutorial - pruebas unitarias php
Tipo de proyectos donde las pruebas unitarias son inútiles (16)
"... es un trabajo de instalación innecesario y que consume mucho tiempo, como apuñalar todas las llamadas a una base de datos y burlarse de objetos de negocios, etc. cuando al final todo lo que necesita saber es si algo le sucedió al DB".
Parece que estás probando lo incorrecto.
¿Por qué rescatar las llamadas a la base de datos? ¿Por qué no crear una base de datos de prueba y probar las llamadas reales a la base de datos de prueba? [Así es como funciona el servidor de pruebas Django, y es genial.]
¿Por qué burlarse de los objetos de negocios? Eso es lo que estás probando, ¿verdad? Está bien decir "asumimos que el ORM funciona" y declarar que su "unidad" es el objeto comercial + base de datos ORM +. Pruébalo, ya que es ahí donde surgen las preguntas.
Unidad prueba las cosas que escribiste.
Las cosas que descargaste deberían tener sus propias pruebas unitarias.
Las pruebas unitarias pueden venir en capas: puede escribir pruebas de integración que supongan que la capa ORM ya pasó todas sus pruebas.
¿Cree que las Pruebas unitarias (y el desarrollo impulsado por pruebas) deben realizarse bajo cualquier conjunto de circunstancias o debería haber algunas excepciones? Últimamente he estado trabajando en el tipo de proyectos en los que no veo cómo sería útil Unit Testing o mejorar el diseño, la calidad del código, etc. Un tipo de proyecto es el generador de informes PDF que toma datos agregados (valores ya calculados y QAed) y lo envía a un archivo de informe PDF. Otro tipo son las aplicaciones directas de CRUD que utilizan la herramienta ORM de terceros. Puedo ver cómo alguien podría argumentar a favor de usar Unit Testing para la aplicación CRUD, pero es un trabajo de instalación innecesario y que consume mucho tiempo, como apuñalar todas las llamadas a una base de datos y burlarse de objetos de negocios, etc. cuando al final todo necesita saber si algo le sucedió a la base de datos. Entonces, cuando uno debería usar o evitar las Pruebas Unitarias?
Gracias
A menudo depende principalmente de las restricciones del cronograma y qué vas a hacer con el código. Si escribe números únicos (que muchos argumentarían que no existen de todos modos), creo que las pruebas unitarias no son necesarias.
Sin embargo, si está escribiendo un software modular que será potencialmente reutilizado o refabricado en el futuro, las pruebas unitarias son muy útiles.
A menudo me parece que el objetivo principal de ellos es no determinar errores en la implementación actual, sino asegurar que no se introduzcan errores cuando lleguen los cambios.
Creo que debería evitar pruebas unitarias en proyectos donde el código no necesita funcionar.
Las pruebas unitarias son extremadamente útiles si desea que el código funcione correctamente ahora y cuando desee que siga funcionando en el futuro cuando haya modificaciones. En proyectos como ese, se paga con creces el ahorro de tiempo, pero en todos los demás es innecesario.
Estoy trabajando en un software que interactúa con una máquina de producción (utilizando algunos estándares de la industria como protocolo de comunicación). Como resultado, la mayoría de los métodos de la clase de comunicador se activan mediante mensajes de la máquina, nunca se llaman desde el exterior. Entonces los hice privados.
Si quiero probar esta funcionalidad, necesito crear un simulador que simule el comportamiento de la máquina, para ejecutar algunas pruebas de caja negra en esta clase. Construir el simulador probablemente tomaría al menos el 50% del tiempo que necesitaba para el comunicador.
Habría hecho públicas las funciones que son activadas por la máquina, pero eso comenzó con algunos argumentos acalorados en nuestro equipo ...
Evite las pruebas unitarias si el valor devuelto por la prueba es menor que el costo de desarrollar y ejecutar las pruebas unitarias. Esto a menudo se reduce al análisis de riesgos y al tiempo de vida esperado de una pieza de código.
Nunca me encontré con una estrategia para probar la capa de visualización de la aplicación que valió la pena.
Aunque me encantaría que alguien me probara mal sobre eso.
Parafraseando los recientes comentarios de Jeff & Joel sobre el SOB: debe hacer pruebas unitarias cuando agrega valor a su producto.
En los dos casos que describe, podría hacer MUCHAS reparaciones ad-hoc (y / o pruebas de regresión post-facto) por el mismo costo que las pruebas de unidad de escritura. Entonces no escribas pruebas unitarias.
Si su código va a ser revisado o usado por otra persona, debe ser probado. Si no a nivel de clase, entonces en un nivel superior. Odio cuando las personas envían su código para su revisión cuando es obvio que no se tomaron el tiempo para molestarse en que funciona (o peor aún ni siquiera compila).
Pocas veces encuentro pruebas unitarias (a nivel de clase) de cualquier valor. Puedo hacer ese tipo de pruebas fácilmente caminando por el depurador cuando estoy desarrollando el código. Prefiero probar las clases que se supone que funcionan juntas como una unidad. Tengo mucho más éxito por el dinero teniendo este enfoque. Después de todo, realmente no me importa si functionX hace exactamente lo que creo que se supone que debe hacer cuando está solo, pero no hace lo que NECESITA hacer cuando trabaja con las otras clases en el sistema.
Yo diría que nunca, simplemente porque la gente ya puede tener una tendencia a realizar menos pruebas unitarias de lo necesario. Si decimos "las pruebas unitarias pueden no ser necesarias", entonces abrimos la puerta a todo tipo de excusas ...
Estoy de acuerdo con Ryan. La única forma útil de pruebas unitarias son las pruebas que están probando algún comportamiento algorítmico, que generalmente es una pequeña parte del programa.
Si te encuentras escribiendo pruebas de unidades útiles, entonces tu trabajo probablemente no sea algo habitual :)
EDITAR: Por el contrario, las pruebas de integración suelen ser muy útiles, pero son mucho más difíciles de automatizar que las pruebas unitarias.
Por ejemplo, escribir pruebas automatizadas para la interfaz de usuario / capa de presentación a menudo no vale la pena. En ese caso, a menudo es mejor mantener la capa de presentación muy delgada y tener una capa comprobable que contenga toda la funcionalidad de la capa de presentación. Entonces, la capa de presentación será principalmente declarativa y solo contendrá un código de pegamento simple. Cuando todo es declarativo, hay poco que pueda romperse, por lo tanto, probarlo no es necesario. Cosas como los elementos de la interfaz de usuario alineados correctamente, es el diseño correcto, las etiquetas son correctas, etc. son más fáciles de probar manualmente.
Código de descarte. Si el código se usará solo una vez, y no es importante que funcione correctamente, y si alguna vez surge la necesidad de modificar el código, puede reescribirlo, puede que no sea beneficioso escribir códigos y pruebas de alta calidad. Pero cuando el código se agranda, o necesita mantenerlo, o es importante que el código funcione correctamente, escribir pruebas vale la pena. Una vez escuché a alguien decir que si escribe más de 10 líneas de código sin pruebas, entonces comienza a dudar si el código que acaba de escribir funcionará correctamente.
Para responder a su pregunta, definitivamente hay algunas excepciones.
De hecho, diría que la utilidad de las pruebas automatizadas de caja blanca es más la excepción que la regla.
Toma tiempo extra, las pruebas tienen que ser reescritas cada vez que haya un cambio significativo, ralentizando e impidiendo el desarrollo. Además, solo porque su pase de prueba no garantiza que su aplicación esté funcionando correctamente o solucionando el problema que está destinado a los usuarios.
Las pruebas de caja blanca con pruebas automáticas han sido una herramienta en la caja de herramientas por un tiempo, últimamente, por alguna razón, está de moda, y si hablas en contra de ello, te vuelven ostracitado por los fanáticos de TDD.
Es mejor entenderlo y usarlo donde pueda ser útil. Por ejemplo, un amigo mío era un SDET en el equipo de Microsoft Frarmework: este era un ejemplo gerat de donde TDD era una gran ventaja. Es decir, estaban desarrollando el motor de un entorno de desarrollo para ser utilizado por millones de personas.
Para su aplicación web run of the mill, incluso a nivel empresarial, sería escéptico que tal rigor valga la pena el tiempo y la complejidad añadidos. Sin embargo, si tiene un componente clave que se usará / volverá a demandar extensivamente, podría valer la pena para esas piezas, etc.
"Una vez escuché a alguien decir que si escribe más de 10 líneas de código sin pruebas, entonces comienza a dudar de si el código que acaba de escribir funcionará bien".
Esta persona es un peligro para sí mismo. Quítelos del código inmediatamente.
La prueba unitaria podría ser parte del proceso de garantía de calidad, pero no debería ser todo el proceso de garantía de calidad.
En general, la prueba de unidad se usa como:
a) algunos QA solo usan la prueba unitaria y esos procesos suelen pasar por alto muchos problemas que no pueden probarse automáticamente. Por ejemplo (y no es tan extraño), chicos perezosos de QA que hacen una prueba de unidad preparada entonces pueden ingresar algunos valores y llamarlo un día.
b) Otros usos de QA como complemento de otra prueba. Sin embargo, las tendencias (¿siempre?) Son redundantes.
Entonces, a menos que la Prueba de la Unidad sea indolora (especialmente a punto de no agregar ni modificar el código), entonces, la prueba en la vieja escuela es la solución (que en cualquier caso, se deben hacer pruebas manuales).
Yo diría que tan pronto como realice una primera función en su proyecto, necesita una unidad para probarla, punto. Si su base de código consiste únicamente en un código de efecto secundario, como el script de shell, por ejemplo, puede hacer otros tipos de pruebas automatizadas, pero si no se trata de un código desechable como describió Esko Luontola, será mejor que escriba cualquier prueba automatizada que termine con ninguna.
Sin embargo, en algunas áreas de la aplicación completa no hay herramientas automatizadas para hacer el control por usted. La GUI y todo lo que se renderiza en la pantalla es un ejemplo, ya que incluso Selenium no tiene la interfaz para verificar automáticamente si la animación que aparece en la ventana modal realmente se reproduce y no tiene fallas. Debe usar una persona real para probar manualmente estas cosas, y es la realidad del control de calidad adecuado.
Su ejemplo PDF es defectuoso en el sentido de que no hay ninguna noción de qué conjunto de características desea probar en el generador de PDF. Si necesita estar seguro de que los datos ya verificados estarán presentes en el PDF resultante, incluso puede hacer algo absolutamente contundente como grep en el archivo en busca de esos datos, porque PDF no es más que un archivo de texto con blobs binarios para imágenes en él, que puede omitir de forma segura en este caso. Si necesita asegurarse de que el formato sea el correcto, en este momento no hay forma de automatizarlo, por lo que lo prueba manualmente.
En el ejemplo de CRUD, no se corta la herramienta ORM de terceros. Escribes una envoltura alrededor, porque en los próximos 2 años la herramienta ORM será reemplazada por algo más brillante o simplemente recibirás alguna actualización incompatible con BC. A continuación, escribe las pruebas de integración de pila completa específicamente para este reiniciador, para asegurarse de que hace lo que su aplicación necesita, y luego se burla del envoltorio en todas las demás pruebas para evitar que dependan del entorno de tiempo de ejecución. Ambos tipos de pruebas son cruciales para evitar regresiones y respaldarlo en la refactorización.
En conclusión, debería tener en cuenta que si le importa en absoluto la aplicación resultante, de todos modos probará la validez de la funcionalidad. El punto es que probar la aplicación manualmente cada vez es una pesadilla que casi no lleva a ninguna prueba. Entonces necesitas las pruebas automáticas. Y para obtener la mejor respuesta, desea que estas pruebas automatizadas se realicen con la mayor frecuencia posible, idealmente de forma constante. Para ello, necesitas que estén locos rápidamente. Y para que el caso de prueba automatizado sea increíblemente rápido, no hay mejor solución que probar solo las cosas relevantes para este caso. Entonces, terminamos con la definición de prueba de la unidad, y lo hicimos de forma natural.
No combine las pruebas unitarias (UT), que es una herramienta, con el diseño impulsado por prueba (TDD), que es una metodología. ver esto para más
Además, recuerde que uno de los beneficios de las pruebas unitarias es para las pruebas de regresión, es decir, como un seguro contra cambios futuros (y para ayudar a verificar que los errores no se solucionen).
En su primer ejemplo, probaría la conversión de PDF de la siguiente manera:
- comience con un conjunto conocido de datos de muestra y genere el documento PDF
- verificar manualmente que el PDF generado sea correcto
- retenga los datos de muestra y corrija el documento PDF como parte del conjunto de pruebas
- escriba una función para comparar dos documentos PDF por diferencias (a nivel binario o de contenido, según corresponda)
- automatice esta prueba unitaria para comparar el documento PDF generado a partir de los datos de muestra con el documento verificado y correcto del primer paso
Ahora, cada vez que cambie el código de generación de PDF, tiene una prueba automática de unidad para verificar que no haya roto la generación de documentos al menos para los datos de muestra y el formato de salida.
Utilicé la misma técnica para verificar páginas renderizadas en HTML, pantallas de GUI, etc. Verifico manualmente la línea base, luego automatizo la comparación después de eso. Esto proporciona un seguro contra futuros cambios de rotura.
Por supuesto, si sus formatos de salida cambian con frecuencia, esto puede no ser tan útil, pero una prueba de línea de base del formato de salida básico es probable que tenga una larga vida útil.
En su segundo ejemplo, parece que estaría probando la herramienta ORM de terceros, que probablemente no tenga sentido. Sin embargo, una vez más, algunas pruebas de línea de base pueden ser útiles como un seguro contra cambios futuros, dependiendo de cómo se utilice la herramienta. Por ejemplo, en lugar de burlarse de toda la cadena de n niveles (no soy fanático de la burla cuando no es necesario), simplemente use la herramienta ORM para crear, leer, actualizar y eliminar un objeto / registro típico, y verifique la operación usando declaraciones SQL directas en la base de datos (de prueba). De esta forma, si el proveedor de terceros posteriormente actualiza algo que rompe la funcionalidad básica, lo sabrá, y los nuevos desarrolladores de su proyecto pueden ver fácilmente cómo usar la herramienta ORM a partir de los ejemplos de prueba de la unidad.