Aplicación de TDD cuando la aplicación es 100% CRUD

Question

Normalmente 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 intento 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 la 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 una con propiedades comunes (por ejemplo, nombre, apellido, correo electrónico de contacto, y asunto y cuerpo y fecha del 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 validar la prueba sea una prueba "útil" porque debe ser algo que el marco de trabajo se encargue de ti)

Answer 1

"El único propósito de la aplicación es, básicamente, extraer una lista de contactos"

Bien. Prueba eso. ¿Qué significa "tirar"? Eso suena como "lógica".

"mostrarlos en una página"

bien. Prueba eso. Los correctos se muestran? ¿Todo allí?

"mostrará un formulario para enviar un mensaje,"

bien. Prueba eso. Campos correctos? Validaciones de entradas todo funciona?

"y similares".

Bien. 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?

Answer 2

Veo lo que está diciendo, pero con el tiempo sus modelos serán lo suficientemente avanzados como para requerir (o ser aumentados 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 mencionas Rails, yo diría que hacer una prueba estándar de crear/leer/actualizar/eliminar es una buena idea para cada propiedad, especialmente porque tu prueba debe tener en cuenta los permisos (creo que esto es enorme). Esto también asegura que tus migraciones funcionen como esperabas.

Answer 3

Estoy trabajando en una aplicación CRUD pura en este momento pero veo un montón de beneficios de casos de prueba Unidad (nota- no he dicho TDD)

escribo código primero y luego los casos de prueba - pero nunca demasiado aparte- muy pronto, aunque

Y pruebo las operaciones CRUD - persistencia a la base de datos también.

Cuando termine con la persistencia, y pase a la capa UI, 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í IMHO- siempre hay beneficio de las pruebas TDD \ Unidad (como se llame en función de cómo extrema se siente al respecto) - incluso para la aplicación CRUD Usted sólo tiene que encontrar la estrategia correcta para- su aplicación

Simplemente use el sentido común ... y estará bien.

Answer 4

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.

Answer 5

sólo una idea ...

Tome los requisitos para la ABM, utilizar 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 potente conjunto de pruebas de regresión para que tenga confianza en cómo realizar la refactorización de manera segura.

esto es solo una idea ...

Answer 6

Saltalo. 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 cree que el proyecto tendrá una duración de 2 semanas y luego nunca se volvió a abrir, pruebas automatizadas, probablemente, es 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 más de hacerlo, pero no "pegan unos cuantos alfileres en ella", por lo que si las cosas empiezan 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 de raspador de pantalla rudimentaria que escribí hace algunos años (escribiendo algunas cosas de 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?

Answer 7

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 S.Lott implícito es que lo que necesita es un conjunto de pruebas de Unidad para probar comportamientos específicos en su aplicación.

Answer 8

En estos días que no deberían tener mucho código escrito a mano para una aplicación CRUD aparte de la interfaz de usuario, ya que hay unos 101 marcos que van a generar el código de base de datos y acceso a datos.

Así que me gustaría ver a reducir la cantidad de código escrito a mano, y la automatización de las pruebas de la interfaz de usuario. Entonces usaría TDD de los bits de lógica que deben escribirse a mano.

Answer 9

TDD Una aplicación CRUD simple 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.? ¿Desea 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ás haciendo TDD es posible que pueda poner a prueba su lógica de la base sin necesidad de utilizar un marco (y esperar un minuto a que cargue/run)