ejemplo - tdd vs bdd
Aplicando TDD cuando la aplicación es 100% CRUD (9)
De forma rutinaria me encuentro con este problema, y no estoy seguro de cómo superar este obstáculo. Realmente quiero empezar a aprender y aplicar Test-Driven-Development (o BDD, o lo que sea), pero parece que cada aplicación que hago donde quiero aplicar es básicamente CRUD de base de datos estándar, y no estoy seguro de cómo para aplicarlo. Los objetos prácticamente no hacen nada aparte de ser persistentes en una base de datos; no hay una lógica compleja que deba ser probada. Hay una puerta de enlace que eventualmente necesitaré para probar un servicio de terceros, pero quiero obtener primero el núcleo de la aplicación.
Cada vez que trato de escribir pruebas, solo termino probando cosas básicas que probablemente no debería probar en primer lugar (por ejemplo, getters / setters) pero no parece que los objetos tengan nada más. Supongo que podría probar la persistencia, pero esto nunca me parece correcto porque se supone que no se debe llegar a una base de datos, pero si se burla, entonces no se está probando nada porque se controlan los datos que se escupieron; como he visto muchos ejemplos donde hay un repositorio simulado que simula una base de datos mediante un bucle y crea una lista de valores conocidos, y la prueba verifica que el "repositorio" puede recuperar un cierto valor ... Estoy no ver el punto de una prueba como esta porque, por supuesto, el "repositorio" va a devolver ese valor; ¡está codificado en la clase! Bueno, lo veo desde un punto de vista puramente TDD (es decir, necesitas una prueba que diga que tu repositorio necesita un método GetCustomerByName o lo que sea antes de que puedas escribir el método), pero eso parece seguir un dogma sin ninguna otra razón que no sea " el camino "- la prueba no parece estar haciendo nada útil aparte de justificar un método.
¿Estoy pensando en esto de la manera incorrecta?
Por ejemplo, ejecute una aplicación de gestión de contactos de fábrica. Tenemos contactos, y digamos que podemos enviar mensajes a contactos. Por lo tanto, tenemos dos entidades: Contact y Message , cada uno con propiedades comunes (por ejemplo, Nombre, Apellido, Correo electrónico de contacto, y Asunto y cuerpo y Fecha de mensaje). Si ninguno de estos objetos tiene un comportamiento real o necesita realizar alguna lógica, ¿cómo aplica TDD al diseñar una aplicación como esta? El único propósito de la aplicación es, básicamente, obtener una lista de contactos y mostrarlos en una página, mostrar un formulario para enviar un mensaje y cosas similares. No veo ningún tipo de pruebas útiles aquí; podría pensar en algunas pruebas, pero serían más o menos pruebas por el solo decir "¡Mire, tengo pruebas!" en lugar de probar realmente algún tipo de lógica (aunque Ruby on Rails hace un buen uso de ella, realmente no considero que probar la validación sea una prueba "útil" porque debería ser algo que el framework se encargue de ti)
"El único propósito de la aplicación es básicamente obtener una lista de contactos"
Bueno. Prueba eso. ¿Qué significa "tirar"? Eso suena como "lógica".
"mostrarlos en una página"
Bueno. Prueba eso. Los correctos se muestran? ¿Todo allí?
"mostrar un formulario para enviar un mensaje"
Bueno. Prueba eso. Campos correctos? Validaciones de entradas todo funciona?
" y similares."
Bueno. Prueba eso. ¿Funcionan las consultas? Encuentra los datos correctos? Mostrar los datos correctos? Validar las entradas? ¿Producir los mensajes de error correctos para las entradas inválidas?
Estoy trabajando en una aplicación CRUD ahora. Lo que estoy haciendo en este punto es escribir pruebas de unidad en mis objetos de repositorio y probar que las funciones de CRUD están funcionando como deberían. He descubierto que esto también ha probado inherentemente el código de la base de datos real. Hemos encontrado bastantes errores en el código de la base de datos de esta manera. Entonces, le sugiero que siga adelante y continúe con las pruebas unitarias. Sé que aplicar TDD en aplicaciones CRUD no es tan glamoroso como las cosas que puedes leer en blogs o revistas, pero cumple su propósito y serás mucho mejor cuando trabajes en una aplicación más compleja.
Estoy trabajando en una aplicación CRUD pura en este momento Pero veo muchos beneficios de los casos de prueba de la Unidad (nota, no dije TDD)
Escribo primero el código y luego los casos de prueba, pero nunca demasiado, pero pronto
Y pruebo las operaciones CRUD: persistencia en la base de datos también.
Cuando haya terminado con la persistencia y continúe con la capa de interfaz de usuario, tendré una gran confianza de que mi capa de servicio / persistencia es buena, y entonces puedo concentrarme solo en la interfaz de usuario en ese momento.
Así que, en mi humilde opinión, siempre hay un beneficio de TDD / Unit testing (como lo llames, dependiendo de lo extremo que te sientas al respecto), incluso para la aplicación CRUD. Solo necesitas encontrar la estrategia adecuada para tu aplicación.
Solo usa el sentido común ... y estarás bien.
Hoy en día no se necesita mucho código escrito a mano para una aplicación CRUD aparte de la IU, ya que hay 101 marcos que generarán la base de datos y el código de acceso a los datos.
Así que me gustaría reducir la cantidad de código escrito a mano y automatizar las pruebas de la interfaz de usuario. Entonces usaría TDD de los bits de lógica que deben escribirse a mano.
Saltarlo. Todo estará bien. Estoy seguro de que tienes una fecha límite para cumplir. (/sarcasmo)
El próximo mes, podemos volver atrás y optimizar las consultas en función de los comentarios de los usuarios. Y romper cosas que no sabíamos que no debíamos romper.
Si crees que el proyecto durará 2 semanas y luego nunca volverá a abrirse, las pruebas automatizadas probablemente sean una pérdida de tiempo. De lo contrario, si tiene un interés personal en "ser dueño" de este código durante unos meses y está activo, realice algunas pruebas. Use su juicio sobre dónde está el mayor riesgo. Peor aún, si planea estar con la compañía por algunos años, y tiene otros compañeros que se turnan para golpear varias piezas de un sistema, y puede ser su turno de nuevo dentro de un año, realice algunas pruebas.
No lo haga en exceso, pero sí "pegue algunos alfileres", de modo que si las cosas comienzan a "moverse", tiene algunas alarmas para llamar la atención sobre las cosas.
La mayoría de mis pruebas han sido pruebas de tipo "diff" de JUnit o de lotes, y una herramienta rudimentaria de raspador de pantalla que escribí hace algunos años (escribir algunas cosas tipo regex + wget / curl). Escuché que Selenium se supone que es una buena herramienta para la prueba de UI de la aplicación web, pero no lo he probado. ¿Alguien tiene herramientas disponibles para aplicaciones de GUI locales?
Siento que estamos confundiendo TDD con Unit Testing.
Las pruebas unitarias son pruebas específicas que prueban las unidades de comportamiento. Estas pruebas a menudo se incluyen en la compilación de integración. S.Lott describió algunos excelentes candidatos para ese tipo de pruebas.
TDD es para diseño. En general, no es tan frecuente que las pruebas que escribo al usar TDD se descarten o se conviertan en una prueba unitaria. La razón detrás de esto es cuando estoy haciendo TDD. Estoy probando mi diseño mientras estoy diseñando mi aplicación, clase, método, dominio, etc.
En respuesta a su situación, estoy de acuerdo con lo que implica S.Lott es que lo que necesita es un conjunto de pruebas de la Unidad para probar comportamientos específicos en su aplicación.
Solo una idea...
Tome los requisitos para CRUD, use herramientas como watij o watir o AutoIt para crear casos de prueba. Comience a crear la interfaz de usuario para aprobar los casos de prueba. Una vez que haya levantado la IU y apruebe tal vez solo una prueba, comience a escribir la capa lógica para esa prueba, y luego la capa db.
Para la mayoría de los usuarios, la IU es el sistema. Recuerde escribir casos de prueba para cada nueva capa que esté creando. Por lo tanto, en lugar de comenzar desde la capa db a la aplicación a la interfaz de usuario, comience en la dirección inversa.
Al final del día, es probable que haya acumulado un conjunto poderoso de conjunto de pruebas de regresión, para darle confianza al hacer la refactorización de manera segura.
Esto es solo una idea...
TDDing una simple aplicación CRUD es, en mi opinión, algo así como practicar escalas en una guitarra: puede pensar que es aburrido y tedioso solo para descubrir cuánto mejora su interpretación. En términos de desarrollo, es probable que escriba código menos acoplado, más comprobable. Además, es más probable que veas las cosas desde la perspectiva del consumidor del código: de hecho lo estarás usando. Esto puede tener muchos efectos secundarios interesantes como API más intuitivas, mejor segregación de preocupaciones, etc. De acuerdo, hay generadores de andamios que pueden hacer CRUD básico para ti y tienen un lugar especialmente para la creación de prototipos, sin embargo, generalmente están vinculados a un marco de tipo. ¿Por qué no centrarse en el dominio central primero, difiriendo las decisiones de Framework / UI / Database hasta que tenga una mejor idea de la funcionalidad central necesaria? TDD puede ayudarlo a hacer eso también. En su ejemplo: ¿Desea que los mensajes sean una cola o un árbol jerárquico, etc.? ¿Quieres que se carguen en tiempo real? ¿Qué hay de ordenar / buscar? ¿Necesitas soportar JSON o solo html? es mucho más fácil ver este tipo de preguntas con BDD / TDD. Si está haciendo TDD, puede probar su lógica central sin siquiera usar un marco (y esperar un minuto para que se cargue / ejecute)
Veo lo que dices, pero con el tiempo tus modelos estarán lo suficientemente avanzados como para requerir (o aumentar en gran medida) las pruebas automatizadas. Si no, lo que esencialmente estás desarrollando es una hoja de cálculo que alguien ya ha desarrollado para ti.
Como mencionó a Rails, yo diría que hacer una prueba de creación / lectura / actualización / eliminación estándar es una buena idea para cada propiedad, especialmente porque su prueba debe tener en cuenta los permisos (creo que esto es enorme). Esto también asegura que tus migraciones funcionen como esperabas.