Hacia un framework de desarrollo guiado por pruebas para Vala - segunda parte - Requisitos y Arquitectura de Sistema

Ya hace menos de una semana desde que lancé un post pidiendo input a mi propuesta de armar un framework de desarrollo guiado por pruebas para Vala y las reacciones han empezado de llegar. Se puede ver un resumen aquí lo que ha sido destilado en una placa de Trello lo que se convertirá en el Product Backlog y el Product Roadmap. La lista me parece más o menos completa hasta ya así que pienso que está al punto de cerrarse y elaborar un Release Plan. Por fin! Puedo empezar a escribir código. Uf!

Los requisitos recopilados hasta ahora son prácticamente iguales con los otros frameworks de pruebas pero este es una buena hora para revisar nuestra Visión de Producto para ver si nuestro rumbo es correcto. He destacado las partes de la declaración que corresponden con características para que podamos compararlas.

Para los desarrolladores de Vala que necesitan probar su código, < insertar el chulo nombre de herramienta > es un framework de pruebas de gran potencia que proporciona funciones de pruebas de las características de comportamiento, funcionales y unitarias para ayudarles a escribir gran software de código abierto. La diferencia con los otros frameworks de prueba y < insertar el chulo nombre de herramienta > es que está diseñado especialmente para Vala, y integra perfectamente en las cadenas de herramientas ya existentes.

Echamos un vistazo a los requisitos que hemos recopilado hasta ya y averiguamos si esas características se caben con esa visión.

proporciona funciones de pruebas de las características de comportamiento, funcionales y unitarias

• Descubrimiento de pruebas
• Pruebas asincrónicas
• Test Runner
• Apoya Gherkin
• Afirmas
• Probar comportamiento protegido
• Pruebas abstractas

diseñado especialmente para Vala

• Apoya Genie

integra perfectamente en las cadenas de herramientas ya existentes

• Emisión de TAP
• Compatible con gstester
• ILC y IGU autónoma
• binarios PIE
• Integrar con herramientas de integración continua como Jenkins
• Las pruebas pueden ser compilados y ejecutado si tener el framework instalado

Hasta aquí todo bien! Por supuesto, este es un proyecto Ágil, así que está lista no es comprensiva ni final y se puede suponer que otras características se añadieren mientras que otras sean modificadas o quitadas completamente. La cosa más importante es que las características se alinea con nuestra visión. El resultado de este proceso de priorización sera el Product Roadmap y el Product Backlog, los cuales guían los sprints y los esfuerzos diarios de desarrollo y informen el programa de lanzamiento. Ante todo eso, necesitamos dirección en como vamos a dividir esas características en áreas funcionales lo que determina como vamos a estructurar nuestra base de código y donde podemos empezar escribiendo pruebas. Para esto, se necesita una arquitectura de sistema.

La arquitectura de sistema y TDD

Uno de los conceptos erróneos que tienen los novatos a TDD es que no escribes nada hasta que hay una prueba. Eso confunde a mucha gente y las deja sin saber donde empezar, como una aplicación sencilla de la linea de comando requiere una cierta cantidad de código repetitivo antes de procesar el input del usuario. Desde este punto, muchos novatos escribirían montones de pruebas redundantes o inventan ruedas ya bien probadas de nuevo o renuncian TDD por completo. Hay pocas veces cuando tu código sera ejecutando sin dependencias (si solo libc) pues siempre estas escribiendo código dentro de un framework existente, si no aproximadamente. La mayoría de estas interacciones con otros frameworks debería ser encapsulado en las pruebas de integración, las que son desarrollada en paralelo con las pruebas unitarias. Las pruebas que informen nuestro diseño de sistema son las que prueban sus características únicas. Nuestra arquitectura de sistema define esas interacciones y limites y nos da un esqueleto básico para empezar a escribir nuestra base de código. Una vez que esta hecha, podemos empezar a escribir las pruebas concretas que nos van a guiar el diseño.

Con un proyecto como este tenemos la ventaja de unas muestras de la técnica anterior, la arquitectura de xUnit siendo la mayor entre ellas. xUnit es un framework flojo que incluye JUnit y Nunit y estipula que cualquier implementación tenga una arquitectura común, como se puede ver en el diagrama abajo.

De este diagrama podemos aun ver como vamos a estructurar el código. Como mínimo, vamos a crear archivos y pruebas distintos para Test, TestRunner, TestSuite, TestCase, TestFixture and TestResult. Si, pruebas para pruebas. Hubiera dicho que esto resultaría interesante... Este nos van a dar el mínimo que necesitamos para armar una cadena de herramientas y crear un repositorio de código. Enhorabuena, estamos al punto de empezar! Salvo que todavía no tiene nombre...

¿Qué tiene un nombre? Lo que llamamos rosa olería tan fragante con cualquier otro nombre.

William Shakespeare

Gracias Guili. Todavía no estoy totalmente entusiasmado con el nombre de Valadate, aunque refleja la Vision de Producto de ser diseñado especialmente para Vala y que no está solamente para las pruebas unitarias. Llamarle VUnit reflejara su procedencia de xUnit pero no es como si hubiera una API rígida para conformarse. Técnicamente en este etapa del desarrollo, no importa nada sino que me gustaría evitar los cambios innecesarios más tarde. Todavía se queda más trabajo antes de empezar escribir código, así que voy a dejarlo filtrarse por una dia o dos antes de tomar una decisión firma. Pues bien, ya es la hora de decir algo si te sientes apasionado de una u otra forma.

Pero por lo menos tiene un logotipo! Dime lo que piensas...

La base fue diseñado por misirlou y agregue los colores chulos. La idea es que simboliza el asteroide epónimo que da el Vala su nombre.

Pues ya está, vuelva a sintonizar prontito cuando voy a hablar de los Roadmap y Backlog además como instale Jenkina CI en un Raspberry Pi.