Cuando haya ideado un diseño/idea general de cómo debería funcionar una parte de un sistema, ¿cómo decide por dónde empezar cuando realiza TDD o, mejor dicho, cómo decide comenzar su primera prueba?¿Con qué prueba unitaria comenzarías?
Supongamos que estoy codificando una clase llamada Oven para hornear mis deliciosos objetos Pie. Así es como me paso a través de la orden de prueba de unidad:
Oven oven = new Oven(); No hay prueba para esta, supongo.oven.turnOn(int degrees) suena bien, lo haré. ¿Cómo lo verifico? Mejor haz oven.getTemperature(). Hay una prueba obvia.Pie. Para eso necesito oven.bake(Pie p) así que lo haré. Pero ahora que? Quiero comprobar si el pastel está listo, pero en lugar de tener oven.isPieReady() creo que oven.pastryStatus() que devuelve cosas como "nada en el horno", "crudo", "casi hecho", "cocinado" y "carbonizado" suena bien y en general debería ser más extensible que oven.isPieReady() así que lo haré.Y así sucesivamente y así sucesivamente. Por lo tanto, haré mis pruebas en orden. Espero usar el objeto refinando la especificación a medida que avanzo. Al final, suelo terminar con una API bastante simple pero potente que hace lo que quiero. Después de probar mi API por unidad, corro la cobertura de mi código para ver lo que perdí y luego agregué pruebas adicionales para eso.
Me gustaría construir un conjunto de unidades para la funcionalidad/nivel más bajo más independiente. Una vez que tenga esas clases pasando cada prueba, puede continuar, asumiendo que funcionarán cuando lo solicite una funcionalidad más dependiente.
estas son las pautas genéricas que encuentro útil para dar prioridad a la unidad de pruebas:
1) Identificar los objetos de contorno (Win/WebForms, CustomControls etc).
2) Identificar los objetos de control (objetos de la capa de negocios)
3) Escribir los tests unitarios para el control de objetos métodos públicos invocadas por objetos de contorno. De esta forma, estarás seguro de que estás cubriendo los principales aspectos funcionales de tu aplicación.
Puede utilizar estas reglas para establecer la prioridad de las pruebas unitarias - a continuación, si es necesario micro-ensayo de otras cosas que usted puede hacerlo también en función de sus necesidades.
Cuando nos enfrentamos a una lista de pruebas para poner en práctica, tendrá categorías
En este caso, elija uno del cubo Categoría2 porque proporcionará un conocimiento/aprendizaje máximo por unidad de tiempo invertido.Además, te hará progresar y aumentará tu confianza para acceder a las pruebas más difíciles de Category3.
Creo que obtuve esto de TDD By Example - Kent Beck. Eche un vistazo en caso de que tenga tiempo ... Recomendado.
interesante. En mi propia experiencia, encontré las pruebas triviales bastante efectivas en la aparición de muchos errores por un mínimo esfuerzo, pero buena comida para pensar. +1 – peterchen
No estoy diciendo 'ignorar las pruebas triviales' ... se necesitan las 3 categorías. :) Solo el orden de tomarlos. Categoría 2 ayuda a despejar la 'niebla de guerra' (para usar un término de juego) en mayor medida, mientras que al mismo tiempo no lo que le permite atascado o pegado con el bloque de TDD Coder. – Gishu
He estado enseñando una clase interna en TDD desde hace un tiempo, y muchos de los participantes comienzan probando todos los casos de error. Por muy relevantes que sean, esa no es la mejor manera de comenzar con imo.
Comience por configurar las pruebas, que son fáciles de implementar y aún le indican si se está moviendo en la dirección correcta con respecto a las funciones que está tratando de implementar. Entonces, si está creando una pila, asegúrese de verificar push y pop antes de probar los casos de error.
Recuerde que el objetivo de la prueba no es solo verificar el comportamiento sino también permitirle usar la interfaz del tipo bajo prueba. Si se siente mal escribir las pruebas, probablemente necesite cambiar la interfaz.
Una buena idea es hacer cada caso de prueba hacia atrás. Así que comience escribiendo la declaración de Assert. Este es el objetivo de la verificación para esta prueba. A continuación, agregue los pasos necesarios para llegar al punto en el que puede hacer lo que hace el Assert.
1 bien hecho, señor – annakata
¿Qué ocurre si se pone Cat C en el horno? ¿Qué hay de poner un pastel "carbonizado" o un pastel que no está listo para el horno? El límite y las pruebas de entrada no válidas son importantes. – Tester101
Esas son las pruebas individuales que refinan las especificaciones, por ejemplo testCantBakeACat() :) Pero sí, límite y no válidas las pruebas de entrada son una de las más importantes que hay y no se debe perder. – Esko