¿Qué pruebas con las pruebas unitarias?

Question

Soy nuevo en pruebas unitarias. Supongamos que estoy construyendo una aplicación web. ¿Cómo sé qué probar? Todos los ejemplos que ves son una especie de función de suma básica que realmente no tiene ningún valor real, o al menos nunca he escrito una función para agregar a las entradas y ¡luego regresar!

Entonces, mi pregunta ... en una aplicación web, ¿cuál es el tipo de cosas que deben probarse?

Sé que esta es una pregunta amplia, pero cualquier cosa será útil. Me interesarían los enlaces o cualquier otra cosa que ofrezca ejemplos de la vida real en lugar de ejemplos de conceptos que no tienen ningún uso real.

Answer 1

Eche un vistazo a su código, especialmente los bits donde tiene lógica compleja con bucles, condicionales, etc., y pregúntese: ¿Cómo sé si esto funciona?

Si necesita cambiar la lógica compleja para tener en cuenta otros casos de esquina, entonces, ¿cómo sabe que los cambios que introduce no rompen los casos existentes? Esto es precisamente lo que la prueba unitaria está destinada a abordar.

Por lo tanto, para responder a su pregunta sobre cómo se aplica a las aplicaciones web, suponga que tiene algún código que establece la página de manera diferente según el navegador. Uno de sus clientes se niega a actualizar de IE6 e insiste en que lo respalde. Por lo tanto, prueba tu código de diseño simulando la cadena de conexión de IE6 y verificando que el diseño sea el que esperas.

Un cliente le dice que ha encontrado un agujero de seguridad donde el uso de una cookie en particular le dará acceso de administrador. ¿Cómo sabes que has solucionado el error y no vuelve a suceder? Cree una prueba unitaria para ello y ejecute las pruebas unitarias diariamente para que pueda recibir una alerta temprana si falla.

Descubrirá un error por el cual los usuarios con acentos en sus nombres se corrompen en la base de datos. Resuma la entrada del formulario web de la capa de la base de datos y agregue pruebas unitarias para garantizar que (p. Ej.) Los datos codificados UTF8 se almacenen en la base de datos correctamente y puedan recuperarse.

Ya entendió la idea. En cualquier lugar donde parte del proceso tiene una entrada y salida bien definida, es ideal para pruebas unitarias.Todo lo que no es ideal para refactorizar hasta que esté bien definido. Eche un vistazo a proyectos tales como WebUnit, HTMLUnit, XMLUnit, CSSUnit.

Answer 2

La primera parte de la prueba consiste en escribir aplicaciones comprobables. Separar la mayor funcionalidad posible de la interfaz de usuario. Refactorizar en métodos más pequeños. Obtenga información acerca de la inyección de dependencia, e intente usarla para crear métodos que puedan tomar datos simples y desechables que produzcan resultados conocidos (y por lo tanto, comprobables). Mire las herramientas de burla.

Infraestructura y código de capa de datos es más fácil de probar.

Observe las pruebas basadas en el comportamiento así como el diseño basado en pruebas. Por mi dinero, las pruebas de comportamiento son mejores que las pruebas de unidades puras; puede seguir use-cases, de modo que las pruebas coincidan con los patrones de uso esperados.

Answer 3

Para una aplicación web, el tipo de pruebas que debe realizar es ligeramente diferente. Las pruebas unitarias son pruebas que evalúan un componente particular de su programa. Para una aplicación web, necesitaría probar que los formularios aceptan/rechazan las entradas correctas, que todos los enlaces apuntan al lugar correcto, que puede hacer frente a entradas inesperadas, etc. Echaré un vistazo al Selenio si fuera usted, Lo he usado extensamente para probar varios sitios: Selenium HQ

Answer 4

No tengo experiencia probando aplicaciones web, pero hablando en términos generales: prueba en unidades los "fragmentos" más pequeños posibles de su programa. Eso significa que prueba cada función de forma individual. Cualquier cosa en una escala mayor se convierte en una prueba de integración.

Por supuesto, va a haber métodos tan simples que no vale la pena su tiempo para escribir una prueba para ellos, pero en general tiene el objetivo de probar la mayor proporción posible de su código.

Answer 5

Pruebas unitarias significa probar cualquier unidad de trabajo, las unidades de trabajo más pequeñas son métodos y funciones. El arte de la prueba unitaria es definir pruebas para una función que no puede verificarse por inspección, a qué unidad apunta la prueba para probar todos los posibles requisitos funcionales de un método.

Consideremos, por ejemplo, tiene una función de inicio de sesión, entonces no puede haber pruebas siguientes que se puede escribir para fallas: 1. ¿ la función a prueba de nombre de usuario y contraseña 2. vacío que hace la función falla en el nombre de usuario correcto, pero la contraseña incorrecta 3. ¿la función de error en la contraseña correcta, pero el nombre de usuario incorrecto

el también sería escribir pruebas de que la función pasaría: 1. ¿el pase función de nombre de usuario y la contraseña correctos

Este es solo un ejemplo básico, pero esto es lo que prueba la unidad pts para lograr, probando cosas que pueden haber sido pasadas por alto durante el desarrollo.

Luego, también existe un enfoque purista en el que primero se supone que un desarrollador debe escribir pruebas y luego el código para pasar esas pruebas (también conocido como desarrollo impulsado por pruebas).

Recursos: http://devzone.zend.com/article/2772 http://www.ibm.com/developerworks/library/j-mocktest.html

Answer 6

Si eres nuevo en TDD, puedo sugerir un viaje rápido en el mundo de TDC? Mi experiencia es que el lenguaje realmente ayuda a las personas a detectar TDD más rápidamente. En particular, se lo señalo en este artículo, en el que Dan Norte sugiere "lo que para poner a prueba":

http://blog.dannorth.net/introducing-bdd/

Nota para la transparencia: Puedo estar muy involucrado en el movimiento de BDD.

En cuanto a las clases de prueba unitaria en una aplicación web, consideraría comenzar con controladores, objetos de dominio si tienen un comportamiento complejo y cualquier cosa llamada "servicio", "administrador", "ayudante" o "util" . Intenta renombrar cualquier clase como esta para que sean menos genéricas y digan lo que hacen. Las clases llamadas "calculadora" o "convertidor" también son buenas candidatas, y probablemente encontrarás más en el mismo paquete/carpeta.

Hay un par de buenos libros que podrían ayudar a usted también:

• Martin Fowler, "Refactoring"
• Michael plumas, "trabajar eficazmente con el código heredado"

Buena suerte !

Answer 7

Una regla de oro es que si no vale la pena probar, no vale la pena escribir.

Sin embargo, algunas cosas son muy difíciles de probar, por lo que tiene que hacer un análisis de costo beneficio en lo que prueba. Si inicialmente busca una cobertura de código del 70%, estará en el camino correcto.

Answer 8

Si comienzas diciendo, "¿Cómo pruebo mi aplicación web?" eso es una mordida de un lote a la vez, y va a ser difícil ver que las pruebas unitarias brinden algún tipo de beneficio. Comencé con las pruebas unitarias comenzando con piezas pequeñas que estaban aisladas, luego escribiendo bibliotecas primero, y luego construyendo aplicaciones completas que podían probarse.

Generalmente una aplicación web tiene un modelo de dominio, tiene objetos de acceso a datos que hacen consultas en una base de datos y devuelven objetos de dominio, tiene servicios que llaman a objetos de acceso a datos y tiene controladores que aceptan solicitudes http y llaman al servicios.

Las pruebas para los controladores verificará que llamen al método de servicio correcto con los parámetros correctos. Los objetos de servicio pueden ser inyectados durante la instalación de la prueba.

Las pruebas de los servicios comprobarán que llaman a los objetos de acceso a datos correctos y realizan la lógica que necesitan para realizar. Los objetos de acceso a datos pueden ser inyectados durante la instalación de la prueba.

Las pruebas para los objetos de acceso a datos comprobarán que realizan la operación correcta de la base de datos (consulta o actualización o lo que sea) comprobando el contenido de la base de datos antes y después. Para las pruebas dao, necesitará una base de datos y una herramienta como DBUnit para rellenarla antes de la prueba. Además, los getters y setters de los objetos de tu dominio se ejercerán con esta prueba, por lo que no necesitarás una prueba separada para ellos.

Las pruebas para el modelo de dominio verificará que la lógica de dominio que haya codificado en ellas funcione (a veces puede que no tenga ninguna). Si diseña su modelo de dominio para que no esté acoplado a la base de datos, mientras más lógica ponga en el modelo de dominio, mejor será porque es fácil de probar. No deberías necesitar ningún simulacro para estas pruebas.