En un nivel más inferior, se utiliza código de pruebas. Esta técnica se denomina TDD. A un nivel más superior, para las características y funcionalidades - se utiliza un sistema similar a Pruebas que llamamos aceptación TDD. A continuación presentaremos una imágen donde se describe la perspectiva de mejorar tanto la calidad externa e interna.
Como podemos observar en la figura 1.1, estos dos distintos niveles, nos permite probar mejor la calidad de software en conjunto con el producto interno e externo. En las siguientes secciones, descubriremos cómo TDD y la aceptación TDD logran estas mejoras. Antes de profundizar en las técnicas vamos a concentrarnos en cómo estas técnicas nos ayudan a ser capaz de superar los retos.
1.2.1 Alta calidad con TDD
TDD es una forma de programación que fomenta el buen diseño y es un proceso disciplinado que nos ayuda a evitar errores de programación. TDD hace que escribamos pequeñas pruebas, automatizado, que con el tiempo permite construir un sistema de alarma muy eficaz para la protección de nuestro código de regresión. No podemos agregar calidad una vez que se ha terminado el software. En el corto ciclo de programación, TDD promueve una buena orientación hacia la escritura de código de alta calidad desde un principio.
El ciclo de corta distancia, es una manera de programación a la que no estamos acostumbrados. Siempre diseñamos primero y luego aplicamos el diseño de alguna manera - No suele ser demasiado profundo - (Después de todo no somos malos programadores al no cometer errores ¿no?). TDD nos enseña a pensar y nos dice que primero debemos escribir las pruebas y sólo a continuación, escribir el código, para alcanzar una meta más clara.
El último paso del ciclo se llama Refactorización. La Refactorización es una disciplina que transforma la estructura o el código de un estado a otro, eliminando la duplicación y poco a poco mover el código hacia un mejor diseño. Con la constante refactorización, podemos hacer crecer nuestra base de código y evolucionar gradualmente nuestro diseño.
Si no estas muy seguro de lo que estamos hablando sobre TDD, no te preocupes, veremos más de cerca este ciclo en el punto 1.3
Resumiendo hasta donde hemos aprendido, podemos decir que, TDD es una técnica de programación que nos ayuda a escribir código probado a fondo y evolucionar nuestro código con los mejores diseño posible en cada etapa. TDD simplemente nos ayuda a evitar el círculo vicioso del código mas escrito.
Hablando de calidad, vamos a hablar un poco sobre este concepto más bien abstracto y lo que significa para nosotros.
La calidad viene en muchos sabores
Se ha demostrado en los departamentos coorporativos de control de calidad que las personas tienden a relacionar la palabra calidad con la cantidad de defectos encontrados después de utilizar un software. Algunos consideran que la calidad se deben a otras cosas tales como, el grado en que el software cumple las necesidades de sus usuarios y sus expectativas. Otros piensan que no basta que se cubra la calidad externa, sino las cualidades internas del software en cuestión (que se traduce a cualidades externas como el costo de desarrollo, mantenimiento, etc).TDD constribuye a mejorar la calidad en todos los aspectos, con su guía de diseño y la orientación a la calidad.
Es posible que la razón número uno, de que un defecto pasé a través de la producción es porque no había niguna prueba de verificación que se haya ejecutado por un camino en particular, sin embargo pensamos que el código funciona como debería. (Otro candidato que se gana el título no deseado es la pereza: no ejecutar todas las pruebas o hacerlo de manera descuidada, dejan un rastro de errores en la aplicación)
TDD es el remedio para esta situación, asegurando que prácticamente no hay código en el sistema, que sea innecesario ejecutar en pruebas. A través de una amplia cobertura de pruebas y automatización de ellas. TDD es la garantía eficaz de lo que se ha escrito en el plan de prueba (en término de defectos) esto permite una buena función en el logro de los correctos casos de pruebas.
Una parte importante de esta tarea es la evaluación del conocimiento. Nuestra capacidad de derivar casos nosrmales de pruebas, casos de borde, usuarios erróneos, y asi sucesivamente.
La forma que TDD puede ayudar en este sentido es centrandonos en las interfaces públicas de nuestros módulos y clases. Al no saber como se comporta una aplicación en la práctica o similar a ello, estamos mejor posicionados para pensar cómo debe comportarse el código fuera de caja. Y se centra cómo debe comportarse el código y cómo el usuario - cliente puede usarlo a prueba de errores.
TDD pone atención a la calidad del código y diseño. Este último tiene un efecto significativo en la cantidad del precioso tiempo que se gasta en nuestro desarrollo. En lugar de corregir defectos, aplicar de nuevas funcionalidades es decir, mejorar el diseño en base al código existente.
Menos tiempo corregir defectos
TDD nos ayuda a reducir el tiempo necesario para reparar defectos. Es común que la fijación de un defecto introducido en un sistema de dos meses toma mucho tiempo y dinero más que arreglarlo en el mismo día de haberlo detectado. Todo lo que podemos hacer para reducir el número de defectos en primer lugar y para ayudarnos es encontrar esos defectos tan pronto o se está obligado a pagar.
Un procedimiento de prueba por primera vez en pequeños pasos aseguran que nunca necesitarán un depurador. Podemos saber que si se agregó un par de líneas que ocasionó la prueba de ruptura, entonces somos capaces de profundizar el origen del problema en muy poco tiempo, evistando aquellas largas sesiones de depuración que amenudo oímos de nuestros colegas. "historias de guerra". Somos capaces de corregir defectos antes, reduciendo costos del proyecto a la empresa. Con cada defecto perdido, significa un costo entre varios dólares. De esta forma evitamos tener que pasar horas y horas mirando el depurador gastando un tiempo que puede servir para otras tareas. El hecho de ofrecer esta funcionalidad significa que tener más tiempo disponible para la limpieza de nuestra base de código, ponerse al día en los últimos avances en herramientas y tecnologías, ponerse al día con nuestros compañeros de trabajo y así sucesivamente - disponer más tiempo para mejorar la calidad, la confianza y la velocidad. Estas son todas las cosas que se necesitan para nuestra capacidad de prueba eficiente, Es un círculo virtuoso y una vez que estás en él, parece no tener fin a las mejoras¡.
Luego, hablaremos más sobre los beneficios de la adopción y la práctica de TDD -beneficios para usted y para nuestros programadores-pero, antes de llegar a ello, vamos a hablar un poco sobre el segundo aspecto de nuestra solución para el desafío. la aceptación TDD.
1.2.2 Necesidad de reunirse con la aceptación TDD.
TDD nos ayuda a construir el código con alta calidad técnica -código que hace lo que esperamos y que el código sea fácil de enteder y trabajar con ellos. La exactitud de desarrollar con TDD nuestro código es gracias a las prueba de bloques aislados, en lugar de las características y capacidades del sistemas. Por otra parte, ni siquiera el mejor código escrito testfirst puede aplicar lo incorrecto, algo que el cliente no necesita. Ahi es donde la aceptación de desarrollo basado en pruebas entra en escena. La forma tradicional de agregar características a un sistema es escribir un documento sobre las necesidades de los requerimientos, proceder a aplicar la prueba funcional de desarrollo , y luego tener la aceptación de las pruebas de los clientes. TDD de aceptación es un método que se diferencia por ejecutar la función antes de ser implementada, como se muestra en al figura 1.2. En otras palabras, traducir un requesito en conjunto de ejecución de pruebas y luego implementar en contra de los casos de pruebas realizados, en lugar de implementar en contra la interpretación del requisito verbal.
TDD de aceptación provee el ingrediente que falta para entregar un buen producto, cerrando la brecha entre el programador y el cliente. En lugar de trabajar fuera de las especificaciones de requerimientos, en el TDD de aceptación nos obliga a acercarnos a colaborar con la definición explícita de los requerimientos arbitrarios, y pruebas inequívocas que nos dicen exactamente lo que quiere decir cuando decimos que una función es "hacer". Al definir la funcionalidad en términos muy concretos - a través de pruebas ejecutables- estamos garantizando de manera efectiva de que estamos entregando lo que el cliente necesita.
El proceso de TDD de aceptación es muy parecido al cliclo de TDD a nivel de código.Con TDD de aceptación , sólo estamos hablando de pruebas de un sistema en lugar de pruebas para el comportamiento de objetos. Esta diferencia significa hablar un lenguaje que el programador y el cliente entiendan.
TDD y TDD de aceptación a menudo van de la mano. A nivel de sistema, ejecutamos procesos de pruebas con TDD de aceptación. Y dentro de la aplicación ejecutamos cada función aplicando TDD. Ellos no son bien acoplados pero, son poderosos en conjunto, y encajan a la perfección.
Ahora debe tener una idea de cómo TDD y la aceptación TDD juntos dan una solución y ser capaz de ofrecer alta calidad de software. Dentro de poco vas a estudiar con más detalle qué es TDD. ¿cómo nos ayuda a crear código de alta calidad y la forma de implemetar correctamente?. En la sección 1.4, vamos a hablar más sobre cómo podemos dejar que las pruebas unitarias de nuestro desarrollo en un nivel superior nos ayudena a satisfacer las necesidades de nuestros clientes- para implementar correctamente- con TDD de aceptación.
Antes de ir más lejos, vamos a hablar cómo nosotros como programadores nos beneficiamos trabajando comprobando el código al principio.
1.2.3 ¿Qué hay para mí?
Nosotros no compramos un auto nuevo sin una razón, y definitivamente no debe adoptar una nueva técnica de desarrollo simplemente porque existe.Tiene que tener algo valioso- algo que mejora nuestra productividad-en fin que tenga sentido en el aprendizaje de una nueva manera de hacer el trabajo. Ya sabemos que TDD y TDD de aceptación nos ayudan a producir software de mayor calidad que cubren las necesidades de nuestros clientes. Vamos a explicar a nosotros mismos cómo estas técnicas hace más agradable la experiencia laboral.
Puedo identificar tres beneficios claros. Personalmente al adoptar diariamente TDD:
- Rara vez me tienen que ayudar a terminar una larga sesión de depuración.
- Me siento confiado en la calidad de mi trabajo.
- Tengo más tiempo para desarrollarme como profesional.
No más depuraciónes prolongadas
Todavía recuerdo de una tarea de programación un par de años atrás. Tengo la fijación de un defecto de dicha tarea, un analizador de cosecha, en un archivo propietario. Había leído cientos de códigos mientras estaba tratando de llegar a abordar el diseño, eventualmente imaginé lo que había que hacer.
El no haber adoptado TDD en ese momento, comenzé a modelar el análisis de diseño imaginando que sería una manera de deshacerme del defecto y hacer que el análisis era fácil de entender. Me tomó un par de horas para btener el nuevo diseño y el compilado del código base. Lleno de entusiasmo con mi diseño con pestañas ultra elegantes y en la ventana final del analizador al servidor, el analizador maldito no funcionó.Simplemente, no funcionó, y no tenía idea por qué. Corrí el código en el depurador, pero todavia no podía entener el problema. Estoy seguro que me tomó como dos horas pasearme por el código con el depurador antes de encontrar el problema y lo resolviera. Y resultó ser algo trivial. Cansado, con hambre y un poco aburrido, me fuí maldiciendo desde la oficina por no haber visto bien el error.
Mucho más tarde me di cuenta que no se trataba de mi ceguera, pero la manera de acercarme a la tarea de búsqueda , es decir el proceso si se quiere, fué un paso demasiado grande, es como perder de vista el árbol en un bósque. Si yo hubiera escrito pequeñas pruebas focalizados en el camino del código, como lo hace TDD, hubiera visto el error inmediatamente, después de escribir la ramificación defectuosa de la construciión.
Como si la sesión de despuración no hubiera sido suficiente, Ley de Murphy (si algo maño puede suceder, sucederá); es demostrado una vez más. Alejandro: pronto recibí una llamada un tanto furiosa debido a que el parser se cayó en el ambiente de producción del cliente. Resulta que introduje al menos un error grave en el parse cuando cambié su diseño. Una cosa es saber que tu código debería exhibir un mejor diseño y es otra ser despertado a las 3 de la mañana por un gerente de cuenta furioso que acaba de ser despertado por un cliente aún más furioso
Sentirse seguro con mi trabajo
En el fondo queremos escribir código que funcione. Nuestros trabajo pueden estar en juego si entregamos código muy errados. Por otro lado, queremos escribir código más rápido dentro de lo posible. Como resultado, a menudo tenemos que decidir cúando estamos lo suficientemente seguros en el código que estamos escribiendo para liberarlo y pasar a la próxima tarea.
Por un momento, vamos a tomar un viaje al pasado. Piense en una programación de sesiones que has experimentado, escribiendo alguna pieza, cualquier pieza de código y piense en los errores que pueden suceder. Tome un minuto para recordarlo.
¿Cómo hicistes para escribir ese código? ¿Lo diseñó por primera vez en un bloc de notas?¿Escribistes el código en una ráfaga, correctamente la primera vez? ¿O has ido hacia atrás y empezar de nuevo?¿La iteración te ha informado de un error evidente?¿Se compila bien en el primer intento?
¿Cómo comprobar que el trozo de código funciona?¿Escribistes un método principal para hacer pruebas? ¿Has hecho clic a través de la interfaz para asegurar que la funcionalidad está bien?¿Te has encontrado errores en el análisis?¿Has tenido que depurar el código?¿Tuvistes que regresar varias veces al código para corregirlo los pequeños problemas? En general, ¿Cúanto tiempo se necesita para probar en comparación con la escritura del código?
Sea cuales sean sus respuestas a estas preguntas, usted ahora ya tiene una idea de las clases de cosas y actividades que usted ha hecho con el fin de poner afuera código de confianza. Con esto en mente, tengo una pregunta para usted.
¿Si pudiera estar seguro de que cualquier código contiene exactamente cero defectos? Si pudiera saber que su código funciona exactamente como dice el requerimiento, su nivel de stress bajaría?¿Si pudiera acelerar las partes lentas de programación, al tiempo aumneta su confianza en la corrección del código?¿Podrñia imaginarse trabajando de esa manera todo el tiempo?
No puedo prometer que la adopción de TDD hará que el software esté libre de defectos. Lo que puedo prometer, sin embargo, es que la práctica TDD le hará sentirse más confiado acerca de su software y le permitirá saber exactamente lo que el código hace.
Esta confianza hace que se haga maravillas en la calidad de nuestro software. Usted podría decir que es un círculo virtuoso. Cuanto mejor sea el conjunto de pruebas, mejor es la calidad de su código y mayor en la confianza ante cualquier cambio. Cuanto más confianza tiene en los cambios que haga, más cambios te atreverás a hacer. Mientras más calidad se haga en el interior del código, más fácil será escribir las pruebas de su código y así sucesivamente.
Más tiempo para otras cosas
TDD y TDD de aceptación no nos va hacer un tipo más rápido, pero nos ayudan a reducir el tiempo de las actividades menos productivas, como la depuración y la maldición del código ilegible, o reprocesos debido a malentendidos sobre los requisitos. A medida que avancemos en pequeños pasos, acumulando pruebas y cada vez más confianza en nuestro código, ya no sienten la necesidad de repetir las mismas pruebas una y otra vez "por si acaso el equipo podría hacer algo diferente esta vez".
Más confianza tenemos, mas rápido podremos pasar a otras tareas, nuestra confianza puede ser falsa, pero, es la ocación que suceda en mi experiencia en superarlo, probando el código suficientemente para transmitir o verificarlo en ella y si los requerimientos se llevan a cabo o no.
TDD y TDD de aceptación no son balas de plata, pero, son más cercanos al legendario proyectil brillante que hemos visto desde la invensión de la máquina. En la siguiente sección, vamos a hablar de TDD en mas detalles. Y lo mismo haremos con TDD de aceptación.
Vamos al grano.
No hay comentarios:
Publicar un comentario