¿Con qué frecuencia prueba el nuevo código / la aplicación mientras implementa una nueva característica? ¿Lo estás haciendo todo de una vez al final o estás probando cada N líneas escritas?

Supongo que estás hablando de la unidad. Entonces mi respuesta reflejará esta suposición. Si desea seguir con el espíritu de TDD, debe escribir su prueba antes de escribir su código real. Básicamente esbozas lo que esperas que haga una unidad en particular. Luego implementa el código de su aplicación real hasta que pase la prueba. Aparte de TDD, siempre debes escribir una prueba. Tan pronto como se agregue o modifique algo nuevo, debe agregar / modificar las pruebas en consecuencia. Tener pruebas actualizadas lo ayudará a detectar errores temprano, especialmente una vez que comience a refactorizar.

Otro beneficio de probar siempre el código de su unidad es que a menudo lo obligará a pensar en DI / IoC. Tener un código débilmente acoplado evitará que pequeños cambios tengan grandes consecuencias.

Depende de la función y de la industria en la que trabaje.

En general, trato de dividir la implementación en fragmentos que se puedan compilar y probar antes de que toda la característica se una. Una característica en la que estoy trabajando ahora me ha llevado varios meses reunirla: puedo agregar código, compilar, probar y depurar aproximadamente una o dos veces al día, por lo que no es como si escribiera durante dos meses y luego depurara durante dos meses. El ciclo suele durar unas 4 horas.

Dicho esto, ha habido algunas cosas en las que he trabajado en las que tal vez estuve codificando durante una semana más o menos antes de poder llegar al punto de compilarlo y probarlo.

Esa es una situación MUY mala, y trato de evitarla.

Pero los recuentos de líneas son una métrica completamente inútil: un mal inventado por la gerencia que no tiene idea de la naturaleza real de la programación … ¡ignórelos siempre que sea posible!

En entornos MUY formales, tal vez software financiero, tal vez sistemas médicos o de transporte críticos para la vida, debe trabajar a partir de las especificaciones, escribir las pruebas PRIMERO y luego escribir el código para pasar esas pruebas. Si pasa todas las pruebas, entonces (en teoría) ya ha terminado. Lamentablemente, los requisitos formales nunca son adecuados, por lo que esta idea idealizada de cómo funcionan las cosas no suele ser la respuesta.

En entornos MUY informales, los videojuegos (en los que he estado trabajando durante la mayor parte de mi carrera), la especificación podría ser nada más que “¡Debe parecer bastante realista, ejecutarse en 0.2 milisegundos y no matar nada más!” no puede escribir pruebas para. Por lo tanto, todo el enfoque formal de arriba y abajo falla desde el principio. La creatividad y el oportunismo es clave. La prueba está en fases:

• ¿Se compila?
• ¿Funciona sin fallar?
• ¿Se ve real?
• ¿Se pierde memoria?
• ¿Interfiere con alguna característica existente?
• ¿Se ejecuta en menos de N microsegundos?
• ¿Todavía se ejecuta en menos de N microsegundos cuando se integra al resto del juego?
• ¿Utiliza una cantidad irrazonable de recursos (memoria, hilos de CPU, memoria de textura, espacio en disco, ancho de banda de red, etc.)?

Cuando llegas al final de esa lista de controles, se lo entregas al equipo de control de calidad que juega el juego y te aseguras de que no rompas nada: dejas que el equipo de arte apruebe la “apariencia” (realismo) – qué tan bien encaja con el estilo artístico del juego). Cuando pasa esas pruebas, pasa a la siguiente característica.

El “ciclo” de desarrollo puede dar la vuelta a ese ciclo completo una vez a la semana, haciendo recorridos más pequeños en algunas de las pruebas un par de veces al día, pero puede durar meses sin ser entregado a QA.

La flexibilidad supera la rigidez en ese tipo de industria.

Depende de lo que estoy escribiendo.

La mayor parte de lo que hago lo hago en Visual Studio, por lo que si es el código de fondo en el que estoy trabajando, implemento una función y la pruebo, implemento una función y luego la pruebo, etc.

Si se trata del código front-end, generalmente tengo mi proyecto VS ejecutándose en vivo en el depurador, para poder ver las llamadas al BE en tiempo real, unirlo con las herramientas de desarrollo de Chrome en un tercer monitor también en tiempo real.

No hay una sola forma de hacerlo, y es como muchas cosas en el desarrollo de software, no hay una sola forma de hacerlo.

Mucha gente pregunta “cómo hago X”, “cómo hago Y”, y la respuesta es siempre la misma, depende de lo que esté haciendo exactamente X y bajo qué condiciones, realmente no hay sólidos fáciles de seguir. reglas para cualquiera de estas cosas, solo tienes que quedarte atrapado y practicar, practicar, practicar.

Eventualmente encontrarás tu propio camino, que funciona para ti.

Esto depende mucho, como se puede deducir de las respuestas de otros.

TDD es genial para algunas cosas. Para otros, es matar o no es realmente posible. Si está codificando un requisito del juego que dice, “codifique una transición de efecto de partículas de la escena … a la escena … eso se siente realmente místico ”. No puedes probarlo unitario.

También he visto equipos sin experiencia escribir el doble de código de prueba TDD que el código de envío que claramente no es efectivo en muchos casos, no en todos los casos.

También debe considerar lo que quiere decir con “prueba”.

• Considerando una aplicación móvil multiplataforma, ‘probar’ podría significar cargarla en un montón de dispositivos de diferentes plataformas para ver si es estable en ellos. Esto debería suceder después de los puntos de finalización de funciones principales, ¡excepto! Si tiene una implementación altamente automatizada y un sistema de prueba de dispositivos …
• Por otro lado, si tiene una idea sobre una construcción de código, pruebe lo antes posible. No se preocupe por las pruebas TDD de su construcción de código, solo juegue con él. Eso puede significar escribir código de prueba o puede significar pasarlo con un depurador. Encuentro que algunas personas escriben código para probar algo muy pequeño que podría validarse en un depurador.

TDD, como todas las pruebas, es un arte. Puede hacer demasiado fácilmente tanto como puede hacer muy poco.

Eso realmente depende de las circunstancias en las que estés programando.

La mayoría de las veces estoy trabajando solo. En este caso, pruebo principalmente cada nueva característica que implemento con alguna excepción si acabo de escribir una función bastante grande donde tiendo a probar este solo.

Cuando trabajo en un grupo, la tendencia se dirige a las pruebas unitarias que felizmente cumplo, pero ocasionalmente me encuentro con una actitud de “Probamos la aplicación cuando está terminada”, donde silenciosamente realizo mi propia estrategia de “prueba de características” :-).

En cuanto a la estrategia de “todas las N líneas”: eso parece ser muy ineficiente para mí, así que trataría de evitarlo.

Voy a responder un poco diferente de los demás.

Cuando escribo código, lo pruebo CONSTANTEMENTE. Cada pequeña función o método, cada pequeño detalle, compilo, ejecuto y pruebo para asegurarme de que lo tengo bien.

Conozco a muchas personas que codificarán primero una clase / módulo completo y luego probarán todo; sin embargo, me he encontrado mucho más eficiente trabajando en piezas pequeñas.

Pruebas unitarias, TDD, como dicen los demás, está muy bien. ¡Pero estoy probando mi código MUCHO ANTES de que las pruebas unitarias estén listas para ejecutarse!

Intento probar con tanta frecuencia como sea funcionalmente significativo, por ejemplo, si estoy escribiendo algo nuevo, buscaré probar y probar los componentes a medida que construyo. Al escribir una variación de algo que he hecho antes, pondré el marco en su lugar, probaré donde creo que está y lo completaré desde allí.

Sin embargo, evito que la codificación de plaga sea profunda antes de iniciar al menos una carrera básica. Nunca falla, no importa cuán experta esté, habrá cometido algún error de lógica en algún lugar y desea detectarlo lo antes posible.

Debería realizar pruebas a partir de la especificación. No debe importarle cómo se implementa, lo que significa que no debe saber cuántas líneas se han escrito. Debe probar sistemáticamente cada característica documentada, incluidos los casos de error.

Lo pruebo cada prueba escrita.

Hay un buen ritmo para TDD donde escribes una pequeña prueba, escribes un poco de código y luego pasas esa prueba.

Una vez que haya hecho esto suficientes veces, su función estará lista.

Si no estoy usando TDD, entonces trato de hacer pruebas con frecuencia. No es tan fácil de hacer, pero el riesgo es demasiado alto de construir cosas que no funcionan

Bueno, generalmente escribo casos de prueba después.

Cuando programo, voy muy lento para no cometer un gran error. También planifico exactamente qué hacer antes de programar para tener un plan de ataque sólido. Como dice el viejo refrán, “lento y constante gana la carrera”.

Gracias por el A2A, Quora User.

Pruebo a medida que avanzo, pero no tengo una métrica establecida para hacerlo. Pruebo cuando parece apropiado hacerlo. No pruebo todo de una vez al final.

¿Con qué frecuencia prueba el nuevo código / la aplicación mientras implementa una nueva característica? ¿Lo estás haciendo todo de una vez al final o estás probando cada N líneas escritas?

Pruebo a medida que avanzo, y la unidad de prueba puede ser tan pequeña como una sola línea de código que hace algo muy específico, un método en una clase o un conjunto de métodos en diferentes clases, todo depende de cómo brota y su Complejidad general. Puedo entrar en una sesión inspirada con un claro resultado final en mi mente y codificar docenas de líneas de código, sabiendo muy bien que está lleno de los errores más básicos, pero quiero obtenerlo todo mientras aún está fresco. Luego lo revisaré para obtener los errores obvios, y luego pruebas más rigurosas como parte del progreso general.