Uso de TDD para crear un informe

Question

Actualmente estoy tratando de usar PHPUnit para aprender sobre Desarrollo controlado por prueba (TDD) y tengo una pregunta sobre cómo escribir informes usando TDD.

En primer lugar: Yo entiendo el proceso básico de TDD:

Pero mi pregunta es la siguiente: ¿Cómo se utiliza TDD para escribir un informe?

Supongamos que le han encargado que escriba un informe sobre el número de automóviles que pasan por una intersección determinada por color, tipo y peso. Ahora, todos los datos anteriores se han capturado en una tabla de base de datos, pero se le pide que lo correlacione.

¿Cómo se hace para escribir pruebas para un método del que desconoce el resultado? El resultado del método que correlaciona estos datos va a cambiar en función del rango de fechas y otros criterios de limitación que el usuario puede proporcionar al ejecutar el informe. ¿Cómo trabajas en los límites de TDD en esta situación usando un marco como PHPUnit?

Answer 1

Crea datos de prueba de antemano que representan el tipo de datos que recibirás en producción, luego prueba tu código con eso, actualizando la tabla cada vez que ejecutas la prueba (es decir, en tu función SetUp()).

No se puede comparar con los datos reales que recibirá en producción sin importar lo que esté probando. Solo está probando que el código funciona como se espera para un escenario determinado. Por ejemplo, si carga su tabla de pruebas con cinco filas de autos azules, entonces desea que su informe muestre cinco autos azules cuando lo pruebe. Está probando las partes del informe para que, cuando termine, haya probado todo el informe automáticamente.

Como comparación, si estuvieras probando una función que esperara un entero positivo entre 1 y 100, ¿escribirías 100 pruebas para probar cada entero individual? No, probarías algo dentro del rango, luego algo dentro y alrededor de los límites (por ejemplo, -1, 0, 1, 50, 99, 100 y 101). No prueba, por ejemplo, 55, porque esa prueba irá por la misma ruta de código que 50.

Identifique las rutas y requisitos de su código, luego cree las pruebas adecuadas para cada uno de ellos. Sus pruebas se convertirán en un reflejo de sus requisitos. Si las pruebas se aprueban, el código será una representación precisa de sus requisitos (y si sus requisitos son incorrectos, TDD no podrá evitarlo).

Answer 2

No utiliza los mismos datos cuando ejecuta los conjuntos de prueba y cuando ejecuta el script. Usas datos de prueba. Entonces, si desea interactuar con una base de datos, una buena solución es crear un sqlite database stored in your ram.

De manera similar, si su función interactúa con un sistema de archivos, puede usar a virtual filesystem.

Y si tiene que interactuar con objetos, you can mock them too.

Lo bueno es que puedes probar con todos los datos maliciosos que piensas cuando escribes el código (hey, ¿y si los datos contienen comillas sin guardar?).

Answer 3

Es muy difícil, y con frecuencia imprudente, probar directamente en su servidor de producción, por lo que su mejor opción es simularlo.

En primer lugar, crea un stub, un objeto especial que representa la base de datos que le permite tener sus pruebas unitarias pretenden que algún valor proviene de la base de datos cuando realmente proviene de usted.Si es necesario, tiene algo que es capaz de generar algo que no le es posible conocer, pero que aún puede acceder a través de las pruebas.

Una vez que todo está funcionando allí, puede tener un conjunto de datos en el DB mismo en algún esquema de prueba; básicamente, se conecta pero con diferentes parámetros para que mientras se vea PRODUCTION.CAR_TABLE realmente esté viendo TESTING.CAR_TABLE . Incluso puede desear que la prueba deje caer/cree la tabla cada vez (aunque eso podría ser un poco demasiado, da como resultado pruebas más confiables).