unit-testing - testeo - tecnicas de pruebas de software

¿Escribes tus pruebas de unidad antes o después de codificar una pieza de funcionalidad?

Question

Me preguntaba cuándo la mayoría de la gente escribió sus pruebas unitarias, si es que lo hizo. Normalmente escribo pruebas después de escribir mi código inicial para asegurarme de que funciona como debería. Luego arreglo lo que está roto.

He tenido bastante éxito con este método pero me he estado preguntando si tal vez cambiar a la prueba de escritura primero sería ventajoso.

Answer 1

Le ofreceré que soy bastante nuevo para escribir pruebas unitarias, y que desearía haberlas escrito antes de escribir mi código. O, al menos, tenía una mejor comprensión de cómo escribir códigos más comprobables, así como una mejor comprensión de conceptos como la inyección de dependencia que parece ser fundamental para escribir código comprobable.

Answer 2

Normalmente escribo pruebas unitarias antes del código. Son muy beneficiosos y los escriben antes de que el código tenga sentido. La inyección de dependencia se presta bien a las pruebas unitarias. La inyección de dependencia permite burlar partes de su código, por lo que solo prueba una unidad en particular, es decir, su código está débilmente acoplado y, por lo tanto, es fácil cambiarlo por una implementación diferente (en este caso, burlada).

Answer 3

Normalmente escribo una lista de las pruebas unitarias que escribiré antes de escribir el código, y en realidad codigo las pruebas unitarias después, pero eso es porque utilizo un programa para generar los resguardo de prueba de la unidad y luego los modifico para probar los casos apropiados.

Answer 4

Realmente quiero escribir el código primero, y a menudo lo hago. Pero cuanto más realizo TDD, donde me niego a escribir cualquier código sin una prueba, más descubro que escribo un código más comprobable y un código mejor.

Entonces, sí, escriba la prueba primero. Se necesita fuerza de voluntad y determinación, pero realmente produce mejores resultados.

Como una ventaja adicional, TDD realmente me ha ayudado a mantenerme enfocado en un ambiente con distracciones.

Answer 5

Sigo un enfoque TDD, pero no soy tan purista como algunos. Normalmente, utilizaré la clase / método con un stub que simplemente arroja una NotImplementedException. Luego comenzaré a escribir la prueba (s). Una característica a la vez, una prueba a la vez. Con frecuencia, me daré cuenta de que me he perdido una prueba, tal vez al escribir otras pruebas o cuando encuentro un error, luego volveré y escribiré una prueba (y la corrección de errores, si es necesario).

Usar TDD ayuda a mantener su código en línea con YAGNI (no lo va a necesitar) siempre y cuando solo escriba pruebas de las características que necesita desarrollar Y solo escriba el código más simple que satisfaga sus pruebas.

Answer 6

Tiendo a usar pruebas unitarias para probar el código mientras lo estoy escribiendo. De esa manera estoy usando lo que estoy escribiendo al mismo tiempo, ya que uso la prueba unitaria para probar el código mientras lo escribo. Al igual que una aplicación de consola lo haría.

A veces incluso he escrito pruebas sin afirmaciones, solo salidas de depuración, solo para probar que la forma en que uso algo está funcionando sin excepciones.

Entonces mi respuesta es, después de un poco de codificación.

Answer 7

Utilizo Test-Driven Development (TDD) para producir la mayor parte de mi código de producción, así que escribo las pruebas de mi unidad primero a menos que esté trabajando en un código heredado no comprobable (cuando la barra para escribir las pruebas es demasiado alta).

De lo contrario, escribo pruebas de aceptación a nivel funcional que el código deberá cumplir.

Escribir las pruebas unitarias primero me permite saber exactamente "dónde estoy": sé que lo que se ha codificado hasta ahora es operativo y se puede integrar o enviar al equipo de prueba; no está libre de errores pero funciona.

Answer 8

Tratamos de escribirlos de antemano, pero lo admitiré plenamente, que nuestro entorno es caótico a veces, y que a veces este paso se pasa por alto y se escribe más adelante.

Answer 9

Siempre que sea posible, trato de seguir un enfoque TDD puro:

1. escribir las pruebas unitarias para la característica que se está desarrollando ; esto me obliga a decidir sobre la (s) interfaz (es) pública (s)
2. codifique la característica lo antes posible (lo más simple posible, pero no más simple)
3. correcto / refactor / retest
4. pruebas adicionales si es necesario para una mejor cobertura, caminos excepcionales, etc. [raro pero vale la pena considerarlo]
5. repetir con la siguiente característica

es fácil entusiasmarse y comenzar a codificar la característica primero, pero esto a menudo significa que no pensará de antemano en todas las interfaces públicas.

EDITAR: tenga en cuenta que si primero escribe el código, es fácil escribir involuntariamente la prueba para cumplir con el código, en lugar de hacerlo de la otra manera.