TDD, ¿Cuáles son tus técnicas para encontrar buenas pruebas?
https://stackoverflow.com/questions/418707
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estoy escribiendo una aplicación web simple usando Linq to Sql como mi administrador de datos, ya que me gusta mucho Linq2Sql. He estado leyendo un poco acerca de DDD y TDD últimamente y quería darle una oportunidad.
En primer lugar, me sorprende que Linq2Sql y DDD no vayan demasiado bien. Mi otro problema es encontrar pruebas, en realidad me resulta muy difícil definir buenas pruebas, así que quería preguntar cuáles son sus mejores técnicas para descubrir buenos casos de pruebas.
Solución
El descubrimiento del caso de prueba es más un arte que una ciencia. Sin embargo, las pautas simples incluyen:
- Código que sabe que es frágil / débil / probable que se rompa
- Siga el escenario del usuario (lo que hará su usuario) y vea cómo tocará su código (a menudo, esto significa depurarlo, otras veces perfilar, y otras veces simplemente significa pensar en el escenario): cualquier punto en su el código es tocado por el usuario, esa es la prioridad más alta contra la cual escribir las pruebas.
- Durante su propio desarrollo, las pruebas que ejecutó resultaron en errores que encontró: escriba pruebas para evitar que el código regrese nuevamente con el mismo comportamiento.
Existen varios libros sobre cómo escribir casos de prueba, pero a menos que esté trabajando en una organización grande que requiera casos de prueba documentados, lo mejor es pensar en todas las partes de su código que no le gusten. (eso no es " puro ") y asegúrate de que puedes probar esos módulos a fondo.
Otros consejos
Bueno, siguiendo la interpretación estándar de TDD es que las pruebas conducen su desarrollo. Entonces, en esencia empiezas con la prueba. Se producirá un error y usted escribirá el código hasta que la prueba pase. Por lo tanto, depende de tus requisitos, sin embargo, vas a reunirlos. Usted decide qué debe hacer su aplicación / función, escribe la prueba y luego el código hasta que pase. Por supuesto, hay muchas otras técnicas, pero esto es solo una breve descripción de lo que generalmente se piensa en el mundo de TDD.
Piensa . Lee el codigo Pregúntate a ti mismo: por ejemplo ¿Puede este puntero nunca ser NULL aquí? ¿Qué pasa si se llama a este método antes de la inicialización?
No haga suposiciones como " este archivo siempre estará allí " Prueba.
Piense en casos de bordes, límites, valores negativos, desbordamientos ...
Los errores a menudo se agrupan por clúster. Mira a tu alrededor cuando encuentres uno. También busque el mismo tipo de error en otras ubicaciones.
Ponga su mente en el objetivo real de las pruebas: encontrar errores.
Sea creativo al imaginar lo que podría hacer que su programa falle.
Sus pruebas deben encontrar errores, no confirmar que su programa está bien.
Regularmente escribo pruebas para API de terceros. De esa manera, cuando se actualice la API, sé si voy a romper o no.
Creo que esta es una técnica útil:
Referencia: Lisa (Ling) Liu, Bertrand Meyer y Bernd Schoeller, Utilizando contratos y consultas booleanas para mejorar la calidad de la generación automática de pruebas , en los procedimientos de TAP: Pruebas Y Pruebas , ETH Zurich, 5-6 de febrero de 2007, eds. Yuri Gurevich y Bertrand Meyer, Lecture Notes in Computer Science, Springer- Verlag, 2007.
