Es todo un mundo nuevo si tu forma de programación es clásica, es decir, recibir las necesidades de tu cliente o usuario final y pasarlo a código durante horas y horas, el TDD, te resetea el chip, ¿Cómo?, de la siguiente manera: Primero creas el código que verificará si los resultados son los correctos de acuerdo a las pruebas que el usuario realizará o al menos tiene la noción de realizarlas para su respectiva aprobación de funcionamiento, y luego, te pones a programar el código fuente principal del software a entregar, si existirá bugs, se asume la refactorización, pero de manera ágil. Te la pintan de manera mágica, es más, para algunos es la salvación, pero hay una gran brecha entre la teoría y la práctica. Así que vamos por partes, y como suelo hacer, vamos por tres partes: Teoría, Planificar y Disfrutar.
Teoría
No quiero expandirme en teoría que encontrarás en cualquier libro de TDD, en tal caso te doy mi opinión para que nutras tus conceptos desde varias perspectivas. Bueno, hay varias buenas universidades en el mundo que presentan en su gama de carreras a Ciencias de la Computación, y en sus cursos de Ingeniería de Software, consideran las pruebas unitarias, tal es el caso del curso 164 de Ciencias de la computación de Harvard (http://www.registrar.fas.harvard.edu/courses-exams/courses-instruction/computer-science). Esto lo obtuve buceando en la página de Harvard. Hay más universidades top donde tienen buena escuela sobre Ciencias de la Computación, si deseas saber sobre el enfoque en Ciencias de la Computación a nivel mundial te invito a ver el top de 50 mejores escuelas que dictan esta ciencia. (http://www.businessinsider.com/best-computer-science-engineering-schools-in-america-2015-7).
Bueno, les cuento una experiencia, a mí me ha tocado entrevistar a varios nuevos egresados de escuelas de Sistemas, Computación e Informática de diferentes Universidades del departamento de Lambayeque para que ingresen a la empresa a la que trabajo; y a cada uno les solté la pregunta “¿Cuéntame tu experiencia sobre TDD, Desarrollo orientado por pruebas?”, y ninguno supo responder, y el 90 % no tenía conocimiento de ello (Considerar que pasaron el examen de conocimientos), eso me hizo pensar que hay que reforzar ese tema en nuestras universidades o al menos incentivar a que lean sobre el tema.
Planificar
Si tienes un software ya construido (es decir varios meses o años de escribir códigos), se te hará difícil pero no imposible trasladarte a este paradigma. Pero si vas a empezar un nuevo proyecto o idea estrella a explotar, te recomiendo que no dejes de lado el TDD, porque automatizar las pruebas te agilizan la forma de desarrollar tu software, pero ojo, el TDD puro va mucho más allá, así que necesitarás expertos y bastante inversión de tiempo.
Les cuento mi experiencia personal, actual, sí, ahora, right now, en la empresa donde trabajamos tenemos un ERP de 5 años de mantenimiento, así que cuenta con 10 módulos aprox., y nunca se han automatizado las pruebas, ni un solo Unit Test, así que como Responsable de Investigación y Desarrollo me estoy encargando de la automatización correspondiente, pero, de la manera más ágil posible (porque estamos madurando para aplicar SCRUM), así que estoy planificando lo siguiente: En primer lugar se debe planificar, es decir, estudiar bien el campo para luego ver como lo atacas, en mi caso, estudiar la arquitectura de software seguido, el tipo de BD utilizado, las interfaces y web services implementados, escenarios complicados (esto es muy importante porque las pruebas unitarias consisten en crear pruebas aisladas e independientes por cada escenario planteado, y dejar todo al finalizar como cuando estuvo al iniciar la prueba, o sea un chambón de ingeniería). Entonces conversando con el Jefe de Desarrollo se estableció arrancar de a pocos para no detener la productividad en paralelo, porque de hecho tendrás que meter mano al código que los desarrolladores están trabajando. (Bueno, un poco para aterrizar, en la empresa estamos utilizando TFS, así que si es un equipo de más de 3 metiendo mano al código, les recomiendo utilizar un repositorio central de fuentes), así que se inició con el módulo core de negocio para nuestros clientes, es decir Ventas (nuestro ERP es para fines comerciales de MYPES), y no todas las clases que conforman el módulo de Ventas, solamente la clase principal, que es Comprobante, y para hacer una prueba de automatización, no a todos sus subs o functions, solo el más representativos, en mi caso elegí el más complejo “Adicionar”. Entonces para empezar deduje que se debe arrancar con refactorizar algunas llamadas, en mi caso, el código no seguía un estándar para manejar parámetros, así que para “Adicionar” indiqué que todo debe ser un parámetro de entrada de tipo DataSet (puedes utilizar objetos si deseas, depende de cada uno), eso establecía que dicho dataset pueda pasarlo a XML y guardarlo una BD exclusiva para pruebas, con ello estaría guardando el “Escenario 1” y según vaya creando más escenario estas se guardaban automáticamente si es que tenía alguna bandera activada, todo en formato XML, para ello y automatizar las pruebas desde un proyecto unit test, hago lectura de todos escenarios con un for construyo un DataSet en base al XML y lo envío como parámetro. Pero si estás en un caso como el mío, donde se utilizan web services, entonces inicia pruebas de integración con los web services, porque si inicias con pruebas unitarias, tendrás que necesitar mucho tiempo para cubrir el 80% de cobertura que te exigen las buenas prácticas de pruebas unitarias.
Disfrutar
Bueno, en mi caso, el disfrute lo tendrán los desarrolladores cuando les entregue el resultado de mi investigación teórico práctico, pero hay que recordar algo, ellos tendrán que construir sus propios escenarios cuando programen, eso conlleva a estimar un tiempo para dicha actividad. Pero se beneficia en el sentido de aprovechar el tiempo en pensar más que hacer actividades manuales repetitivas, ese tiempo perdido se plasma ahora en programar los escenarios, así que ahora ese tiempo se utilizará para entrenar tu cerebro. En mi caso me estoy dividiendo entre la implementación y despliegue de ISO 9001 para la empresa donde trabajo e investigar aplicar TDD al 100%, por lo que poco a poco se está avanzando con TDD. De hecho lo ambiciosos es llegar a un DevOps total, incluyendo pruebas del fantasma (pruebas UI), pruebas unitarias al 80%, aplicación de mocks, stubs, etc.
De hecho que hay un montón de cursos, diplomados, certificaciones, etc., pero si no se ponen en práctica es lo mismo que nada. Este post es un bebé en pañales, estoy en casi nada, pero nunca es tarde para iniciar. Estoy seguro que en un futuro estaré posteando como fuimos avanzando y cuanto hemos madurado respecto a este tema. Disfruten de la Ingeniería del Software, programen!.
No hay comentarios.:
Publicar un comentario