.net - ejemplo - abbr significado

¿Debo usar TDD? (15)

Soy el único desarrollador en mi (muy pequeña) empresa y estoy por comenzar una aplicación web ASP.NET de tamaño mediano para dicha compañía.

Estoy tratando de averiguar si debo aprender Test Driven Development (TDD) e implementarlo en esta aplicación.

Necesito comenzar a desarrollar nuestra nueva aplicación en breve y estoy preocupado por las pruebas. He programado durante muchos años, pero nunca he hecho ninguna prueba unitaria.

He leído numerosos recursos en línea con respecto a TDD, pero no estoy seguro de si tendré una comprensión "lo suficientemente buena" para hacerlo efectivo en la aplicación.

¿Tiene componentes que sean fácilmente comprobables por unidad? ¿Puedes construir tu aplicación para que sea un conjunto de componentes comprobables por la unidad? Esa es realmente la mentalidad para pensar cuando se trabaja en un entorno TDD.

Es fácil decir "¡es una aplicación GUI! ¡Es imposible probar mis cosas!" Esta puede ser una profecía autocumplida. Ciertamente, no es fácil probar el diseño de todos sus widgets, pero ¿qué parte de su programa está relacionado con la distribución de sus widgets? Puede dejar de hacer un buen TDD porque algún aspecto está demasiado unido al diseño de los widgets de su GUI, o está demasiado unido a algo que no es fácilmente inestable. Detente y desafíate a ti mismo: ¿este es realmente el caso? ¿Puedo compartimentar y modularizar mi código de modo que pueda aislarse mejor de estas partes del sistema? ¿Es apropiado hacerlo (las ganancias de prueba unitaria ameritan el costo?). No acepte carte blanche que es imposible solo porque su software está vinculado a componentes no inestables.

Caleb - Quería lanzar un sitio que se ha construido para ayudar a aprender TDD por ti mismo en casa. Aprende mejor si no está bajo presión. Simplemente busque "problemas tdd" en google y lo encontrará.

Depende de dónde se encuentran sus prioridades. Si está interesado en promoverse a sí mismo como desarrollador, definitivamente vale la pena investigar el TDD solo por la experiencia. Te ayudará a replantearte la forma de codificar y, probablemente, a convertirte en un mejor desarrollador gracias a él.

Pero eso podría compensarse fácilmente por cuánto TDD dificulta su capacidad de sacar su producto de manera oportuna. Usted mencionó que usted es el único desarrollador que trabaja en esta empresa y eso significa que la presión recae en usted para que se realice su proyecto. TDD es sin duda una gran práctica, pero a veces las limitaciones de la vida real y la practicidad deben ser prioritarias.

En resumen, si puede dedicar tiempo, entonces sí, use TDD. En realidad, no es demasiado alto y siempre se puede omitir la prueba en un apuro. Pero si realmente tiene poco tiempo y no cree que pueda incorporarlo sin poner en riesgo su producto y su trabajo, nadie le fallaría por omitirlo. Los puristas estarán en desacuerdo, pero no es un mundo en blanco y negro y, a veces, hay que hacer concesiones para hacer las cosas.

La mejor forma de aprender es haciendo. Si ha leído mucho al respecto, es hora de sumergirse, y como un solo desarrollador, tener pruebas unitarias puede ser una bendición, ya que no hay otro par de ojos para revisar su código.

La sobrecarga de TDD se reduce a medida que adquiere experiencia en ella, y pronto se convierte en algo menor que la sobrecarga de no desarrollar usando TDD.

Sin embargo, los gastos generales para empezar pueden ser significativos, perderá tiempo haciendo las cosas mal por falta de experiencia. Un proyecto crítico es un lugar arriesgado para incluir el tiempo que toma aprender una nueva técnica de desarrollo

No puedo enfatizar lo suficiente las ventajas de un método de desarrollo basado en TDD. Cuando adoptas TDD, tus pruebas unitarias se convierten en ciudadanos de primera clase junto con el código que escribes, en lugar de ser un código que se mantiene por el motivo de tener pruebas unitarias y no se mantiene actualizado.

En TDD, utiliza sus pruebas unitarias como una especificación ejecutable de lo que su componente debería hacer. Haría esto considerando qué quiere que haga su componente, y luego escribiendo pruebas para ejercer esta funcionalidad. Como su código inicialmente no tendrá ninguna de estas funciones, todas las nuevas pruebas que escriba fallarán o serán rojas. Una vez que tenga sus pruebas, comience a implementar el componente. Poco a poco, a medida que agrega la funcionalidad requerida, las pruebas rojas se volverán verdes. Lo bueno es que después de que haya implementado la funcionalidad suficiente para que todas sus pruebas pasen, usted sabe que ha completado la implementación de la especificación prevista y sabe exactamente dónde detenerse. Demasiado a menudo he visto situaciones en las que un desarrollador habrá completado la implementación de la funcionalidad requerida pero no se detiene, en lugar de eso, mejora el componente y agrega funcionalidades adicionales y llamativas, ninguna de las cuales es parte de la especificación requerida, desperdiciando tiempo de desarrollo activo .

Una vez que tenga sus pruebas unitarias, es fácil configurar esto en un entorno de integración continua. Este entorno verificará el código más reciente de su repositorio, lo construirá y luego ejecutará sus pruebas unitarias. Si ocurre alguna regresión, si alguien ingresa un código que rompe sus pruebas unitarias, lo sabrá pronto, en lugar de descubrirlo luego de que se haya desplegado en su entorno de producción. Para asegurarnos de que el nuevo código no introduzca una regresión, hemos configurado login-hooks en nuestro repositorio para garantizar que todo el código enviado también tenga las pruebas adjuntas y que pasen. Esto es especialmente útil cuando tienes varias personas trabajando en un proyecto, ya que pueden ver a través del tablero de monitoreo que puedas usar si el repositorio es bueno para sincronizar en ese momento o no. También es fácil ubicar una versión particular del repositorio que funciona, permitiendo que la gente trabaje con versiones conocidas, mientras que otra persona está trabajando en solucionar cualquier problema que esté actualmente rompiendo su compilación. Esto también podría significar potencialmente que cualquier compilación ''ecológica'', como lo indica el tablero, es una compilación que tiene una muy buena probabilidad de no encontrarse con problemas cuando se la envía a un entorno de producción.

Mucha gente piensa que adoptar TDD significaría trabajo extra y molestias, y que consumiría más tiempo. Sin embargo, tenga en cuenta que el tiempo extra dedicado a escribir pruebas evitará que se rompa ninguna funcionalidad que se esté probando, y que encontrará los descansos más pronto, en lugar de más tarde.

Otra ventaja del uso de TDD es que le dará mucha más atención a su diseño y estará mucho mejor estructurado y compuesto por un enfoque que no sea TDD. Esta componente es importante para poder tener un conjunto de pruebas unitarias que sea rápido de ejecutar y no frágil.

La prueba GUI es difícil, pero no imposible. Considere tecnologías de prueba de interfaz de usuario web como Selenium, WebDriver y Watir, que pueden usar interfaces de usuario web mediante programación. Es fácil hacer un mal uso de estas herramientas también, al realizar pruebas costosas de extremo a extremo. Un enfoque mucho mejor es abstraer su capa de interfaz de usuario para que pueda probarse aisladamente, independientemente de su lógica comercial. No desea que se ejecute una prueba de UI y realizar operaciones en una base de datos.

Para recapitular, desea escribir pruebas unitarias eficientes para hacer que el uso de TDD sea una experiencia agradable, en lugar de una carga. Sus pruebas deben ser rápidas, pruebe los componentes de forma aislada e idealmente debe ejecutarse todo el tiempo.

Lo que he descrito aquí es un caso ideal. No tiene que adoptar todas y cada una de las ideas mencionadas, pero puede escoger y elegir lo que funcione para que su proceso de desarrollo sea más eficiente.

Pensé que resumiría y comentaría algunos de los comentarios anteriores:

Sí, TDD se trata de diseño. No se trata de probar.
No estoy seguro de por qué QA se involucró con la etapa de diseño de George. Parece que estaban especificando pruebas automáticas. Como Tim señaló, es un proceso de desarrollo.
Kevin, dijiste ''salta las pruebas''. Una vez más. TDD se trata de diseño, NO se trata de pruebas. OK Puede omitir el diseño, pero la aplicación terminada tendrá fallas y será insoportable.
Roshan mencionó, ''especificación ejecutable de lo que tu componente debería hacer''. Eso significa documentación completamente actualizada. Cuando eres nuevo en un proyecto, puedes ponerte al día rápidamente, puedes ver exactamente lo que el desarrollador original quiso. Y, como mencionó Jon, puedes hacer cambios de código y asegurarte de que no haya nada roto.

Recientemente comencé a usar TDD en todos los códigos nuevos. Sí, al principio parecía que era solo una pérdida de tiempo, ya que toda mi lógica estaba demasiado ligada a la Gui, así que no podía escribir ninguna prueba de unidad que realmente pudiera garantizar que mi código hiciera lo que debería hacer.
Pero después de un tiempo me di cuenta de que escribir pruebas unitarias era un gran dolor porque el código estaba mal escrito. Empecé a refactorizar mi código de tal manera que podía escribir pruebas de unidad que importaban. Comencé a hacer que mis métodos fueran más cortos, hice más uso de las interfaces y traté de separar la lógica lo más posible del Gui.
Creo que el propósito de usar pruebas unitarias además de probar y validar tu código es simplemente convertirte en un mejor programador general. De todos modos, vale la pena el esfuerzo de aprenderlo.

Recuerda esto: la única prueba mala es la que no ejecutas.

Ahora, ¿necesitas bucear directamente en TDD? Tal vez no. Pero definitivamente deberías comenzar a probar la unidad todo lo que puedas. No se puede probar la unidad de interfaz gráfica de usuario muy bien, y eso está bien, guardarlos para UAT.

¿Pero algún tipo de lógica que puedas ejecutar detrás de escena? Sí, deberías probarlo.

Comience simplemente tratando de probar métodos individuales. A medida que avanza, comenzará a sentir dolor, porque lo más probable es que su código no esté diseñado para ser probado. Esto esta bien; refactoriza tu código! Sigue haciéndolo hasta que puedas probar tu código. Recuerda lo que tienes que hacer y hazlo la primera vez la próxima vez que escribas código.

Después de algunas iteraciones, aprenderá lo que necesita aprender (en realidad, solo puede aprender haciendo) y el dolor desaparecerá. Cuando eso suceda, sugeriría que probablemente estés listo para investigar TDD.

Si se hace de manera pragmática, puede ser un gran beneficio. El argumento en contra de esto siempre parece ser que lleva demasiado tiempo, pero como todos sabemos, si muchos casos sacrifican a sabiendas la calidad puede ser incluso más perjudicial.

Han pasado 3 años desde que aprendí TDD y puedo decir honestamente que lo he visto aportar un gran valor y también lo he visto como una completa pérdida de tiempo.

Aquí hay un ejemplo de cada ...

Beneficioso: trabajando en una solución que era bastante compleja, tenía muchas dependencias y variaciones y estaba en constante evolución. Diseñar con las pruebas en mente y tener un conjunto de pruebas de unidades de regresión nos permitió adaptarnos para cambiar rápidamente y poder refactorizar el código para aumentar el mantenimiento. Usamos la regla 80/20 cuando creamos pruebas unitarias y omitimos casos de prueba de bajo valor.

No es beneficioso: se decidió (dogmáticamente) que debíamos tener una prueba automatizada para cada caso de prueba en la que se pudiera pensar QA, incluso casos de IU. Muchos casos eran muy rudimentarios e involucraban un código muy pequeño, muy simple. Conseguir que muchos de ellos funcionaran requería grandes cantidades de configuración y aumentaba la cantidad de pruebas para mantener tanto que nos ralentizaba significativamente.

Sigo siendo un desarrollador nuevo y entré en una empresa donde el desarrollo de aplicaciones ya estaba en curso. TDD me ayuda a garantizar que los nuevos cambios no rompan lo que ya se ha hecho y, a medida que avanzo, me ayuda a tener que hacer una gran cantidad de búsquedas de errores cuando agrego o modifico el código.

Me encantó todo lo que aprendí de él y recomiendo encarecidamente tomarse el tiempo para aprender TDD.

-my .02

Solo un desarrollador es en realidad un esfuerzo de desarrollo bastante pequeño. Incluso si espera una gran cantidad de pantallas, todavía tarda mucho tiempo para que un único codificador entre en algo medio (a menos que se hayan vuelto locos al cortar y pegar).

No soy un gran admirador de TDD, pero si eres un programador relativamente nuevo (menos de 10 años), estás solo y te preocupan los problemas de calidad, estoy seguro de que te ralentizará, pero también ayuda a mejorar tu trabajo Para los programadores más jóvenes les obliga a centrarse más intensamente en el comportamiento subyacente real del código y hacerlo funcionar paso a paso (un error común temprano es demasiado pesado en cantidades masivas de código, y luego tratar de depurarlo todo a la vez Los viejos codificadores pueden salirse con la suya, los más jóvenes usualmente necesitan trabajar en piezas más pequeñas a la vez). Los fanáticos a menudo dicen que cambió principalmente la forma en que codifican (generalmente facilitando el trabajo general). Por lo menos, podrías comenzar con esto y abandonarlo más adelante si no está realmente ayudando.

Su mayor problema, para el cual TDD no ayudará, es obtener una buena estructura arquitectónica para la aplicación web. Uno que no querrás tirar en cinco meses. Las aplicaciones web pueden ser muy difíciles, pocas personas lo hacen bien en las primeras diez o doce veces.

TDD es una gran práctica y no puedo hablar mejor de eso.

Sin embargo, si estuviera en su posición, no me preocuparía tanto por TDD por el momento, sino que me concentraría en tener algunas buenas pruebas de unidad alrededor de su código.

Siempre puede comenzar a usar TDD un poco más adelante en su proyecto, cuando se presenta la complicada lógica de negocios.

No me gustaría que tengas una mala experiencia con TDD, lo que podría suceder si estás bajo presión de entrega y no tienes experiencia en el uso de la práctica.

Podría ser una idea probar algunos TDD Katas en casa para familiarizarse con él, antes de usarlo en el trabajo.

Algunos buenos Katas se pueden encontrar here

TDD, pseudo TDD y cuasi TDD. Muchos enfoques diferentes Solo depende de quién aplica el nivel de TDD. Muchos pros y contras también, de nuevo depende de su personal. Esta es una de esas filosofías de espadas de doble filo. Si no sabes lo que estás haciendo o hay un nivel separado de comprensión dentro de tu (s) grupo (es), te atascará y provocará luchas internas, lo que eventualmente llevará a eliminar el TDD por completo. También TDD es diferente de (solo escribe pruebas).

Tenga en cuenta que TDD no se trata de pruebas; es un proceso de desarrollo. La prueba no se realiza para reemplazar la función de prueba: es lo que define el proceso de desarrollo.

Parece que estás hablando de pruebas unitarias y otras pruebas automatizadas. La prueba es buena. Las pruebas automatizadas son buenas. No tengas miedo de cometer errores. Si piensa en su código y cómo automatizar las pruebas tanto como sea posible, entonces se encuentra en una buena posición; sin embargo, hay un corte de rendimientos decrecientes. Es probable que las pruebas 100% automáticas no sean rentables, especialmente para una organización que usted describe.

Si realmente está hablando de TDD (lo que los expertos llamarían TDD), eso también puede ser bueno. Hay muchos procesos de desarrollo. Es bueno recordar que los procesos de desarrollo son marcos y guías, no una religión a seguir como una búsqueda. Ningún proceso es de una sola talla para todos. Haz lo que tenga sentido para ti y mejora a medida que avanzas. Tener solo una persona en una organización de desarrollo hace que el proceso de cambio sea bastante sencillo. Aborde primero sus problemas de alto riesgo y aplique un proceso liviano para aquellos antes de abordar problemas de bajo valor.