Las pruebas unitarias tienen sentido en el proceso TDD. No tienen mucho valor si no haces el desarrollo de prueba primero. Sin embargo, la prueba de aceptación es una gran cosa para la calidad del software. Yo diría que la prueba de aceptación es un santo grial del desarrollo. Las pruebas de aceptación muestran si la aplicación cumple con los requisitos. ¿Cómo puedo saber cuándo dejar de desarrollar la función, solo cuando pase toda mi prueba de aceptación? La automatización de las pruebas de aceptación es muy importante porque no tengo que hacerlo todo de manera manual cada vez que realizo cambios en la aplicación. Después de meses de desarrollo, puede haber cientos de pruebas y se hace inviable (en algún momento imposible) ejecutar todas las pruebas de forma manual. Entonces, ¿cómo sé si mi aplicación todavía funciona?
La automatización de las pruebas de aceptación se puede implementar con el uso de marcos de prueba xUnit, lo que genera confusión aquí. Si creo una prueba de aceptación usando phpUnit o httpUnit, ¿es una prueba unitaria?Mi respuesta es no. No importa qué herramienta utilizo para crear y ejecutar la prueba. La prueba de aceptación es la que muestra si las características funcionan según los requisitos de IAW. La prueba de unidad muestra si una clase (o función) satisface la idea de implementación del desarrollador. La prueba unitaria no tiene valor para el cliente (usuario). prueba de aceptación tiene un gran valor para el cliente (y por lo tanto al desarrollador, recuerde Customer Affinity)
Así que recomiendo la creación de la aceptación automatizado prueba para la aplicación web.
Los buenos marcos para la prueba de aceptación son:
- Sahi (sahi.co.in)
- Silenium
- SimpleTest (I't un marco-test unidad para php, pero incluye la objeto del navegador que se puede usar para las pruebas de aceptación).
Sin embargo
Se han mencionado que sitio web tiene que ver con la interacción del usuario y por lo tanto la automatización de pruebas no va a resolver todo el problema de usabilidad. Por ejemplo: el marco de prueba muestra que todas las pruebas pasan, sin embargo, el usuario no puede ver el formulario o enlace u otro elemento de página debido a style="display:none" accidental en el div. Las pruebas automáticas pasan porque el div está presente en el documento y el marco de prueba puede "verlo". Pero el usuario no puede. Y la prueba manual fallaría.
Por lo tanto, todas las aplicaciones web necesitan pruebas manuales. La prueba automatizada puede reducir drásticamente la carga de trabajo de la prueba (80%), pero la prueba manual también es importante para la calidad del software resultante.
En cuanto a la prueba de unidad y TDD, hace que la calidad del código. Es beneficioso para los desarrolladores y para el futuro del proyecto (es decir, para proyectos de más de un par de meses). Sin embargo, TDD requiere habilidad. Si tienes la habilidad, úsala. Si no considera adquirir la habilidad, pero tenga en cuenta el tiempo que le llevará ganar. Por lo general, toma de 3 a 6 meses para comenzar a crear un buen examen y código de unidad. Si el proyecto durará más de un año, recomiendo estudiar TDD e invertir tiempo en un entorno de desarrollo adecuado.
I segundo esto. No verá el valor hasta que salve su trasero. Entonces te preguntarás cómo dormiste por la noche sin eso. :) – cwash
Bien, pero ¿qué quiere decir con la prueba de integración? ¿Como lo harias? –
Una prueba de integración prueba la funcionalidad de extremo a extremo. Las pruebas de unidad normal solo prueban la función/método que desea probar, nada más. Por ejemplo, para probar un método en la lógica de su negocio que obtiene una lista de clientes de una base de datos, podría falsificar la base de datos. Una prueba de integración, sin embargo, iría hasta la base de datos y viceversa, para probar cómo funciona todo junto. Lo mismo en una página web. Con WATIN o Selenium, puede acceder a la página web que desea probar y asegurarse de que los datos se devuelvan correctamente, etc. La prueba aplicará todos los niveles de su código. – Doanair