He escuchado mucho sobre pruebas unitarias últimamente.¿Cuándo/Cómo probar las aplicaciones CRUD?
Lo que estoy tratando de entender es cómo podría uno/debería uno hacer una prueba de unidad de una aplicación de negocios cruddy? (básicamente, una aplicación que escribe datos en/lee datos de una base de datos).
¿Las pruebas unitarias incluso valen la pena en ese escenario o generalmente pruebas las cosas más complicadas?
Gracias
Las pruebas unitarias se trata de pruebas de unidades discretas de código - un método único, no más.
En el momento en que ingresa a CRUD, está hablando de probar redes, IO, bases de datos y otras cosas; esto va más allá de lo que se trata la prueba unitaria. En este caso, esto se denomina prueba de integración (está probando cómo su código se integra con otros códigos/sistemas).
Hay lugar para ambos tipos de pruebas (y otros tipos - regresión, rendimiento, etc ...) en cualquier proyecto de software, aplicación CRUD o no.
La prueba de unidad puede probar diferentes SUT (Sistema bajo prueba): dos métodos o incluso varias clases. La diferencia entre las pruebas unitarias es muy difusa y no existe una definición clara del tamaño y los atributos del SUT de las pruebas de integración o unidad. –
@Yauheni Sivukha - De wikipedia: Una unidad es la parte más pequeña comprobable de una aplicación. http://en.wikipedia.org/wiki/Unit_testing – Oded
@Odded - Wikipedia no dice que la parte más pequeña comprobable es el método. Depende del contexto Si la prueba verifica los totales en orden, entonces debe completar las líneas de pedido. Por cierto: http://stackoverflow.com/questions/10752/what-is-the-difference-between-integration-and-unit-tests –
La prueba de unidades se trata de probar PEQUEÑOS bits simples de funcionalidad. Por lo general, debe probar la capa de datos de la aplicación que manejaría toda la funcionalidad de CRUD. Una prueba para un crear y recuperar podría tener este aspecto:
PrimaryKey = InsertObject(TestObject)
if PrimaryKey = 0 then
AssertTestFailed("Primary Key Not Returned.")
end if
NewInstanceOfObject = GetObject(PrimaryKey)
If NewInstanceOfObject <> TestObject then
AssertTestFailed("Record not located.")
else
AssertTestPassed("This Code is awesome UnitTest Passed.")
end if
Si todo su aplicación hace es CRUD, entonces no hay ningún punto en la unidad de probarlo. Ahora, si hay algún tipo de lógica empresarial que manipule los valores a medida que salen de la base de datos o los validen antes de que entren, sí, es una buena idea crear pruebas unitarias. La prueba de la parte CRUD no pertenece a la unidad de prueba de la OMI.
Las aplicaciones de Cruddy rara vez se quedan cruddy. Eventualmente crecen para incluir una capa de objeto comercial.
Así que, sí, haría pruebas unitarias. Incluso una aplicación cruddy básica debe dividirse en una capa de interacción, una capa de acceso a datos y la interfaz de usuario increíblemente simple (tenga en cuenta que todo el estado de la interfaz de usuario se debe mantener en la capa de interacción). Eventualmente, probablemente obtendrá una capa de objeto comercial entre las capas de interacción y acceso a datos.
Sé que todo el mundo sigue y sigue sobre cómo debe probar primero, el diseño de todo, pero tiendo a seguir con la unidad de pruebas de cosas más complicadas.
Mi regla de oro es que construyo pruebas automatizadas para cosas que realmente espero romper con la regularidad, o cosas que no notaré de inmediato están rotas. Y, sobre todo, quiero que pruebe cosas que no puedo/no volveré a ponerme a prueba. Por ejemplo, el módulo "Calcular algunas cosas grandes complicadas usando 47 variables diferentes" debería tener un montón de pruebas que logren una buena cobertura de código y cubran todas las rutas de código posibles, pero el código que efectivamente guarda ese resultado de nuevo en el la base de datos no necesariamente necesita una prueba, especialmente si está haciendo un simple trabajo CRUD.
Además, me gusta usar pruebas de UI automatizadas (usando WatiN o algo similar) para construir pruebas de regresión para mis sitios, de modo que cuando cambio algunos componentes básicos pueda ejecutar una verificación de cordura para asegurarme de que no explotar una esquina obscura del sitio.
Al final, se trata de ROI. ¿Cuánto tiempo dedica a esto y cuánto está obteniendo de él?Si las pruebas de su unidad se están acercando al 100% de cobertura de código en alguna estúpida capa de acceso a datos de su aplicación comercial CRUDy, está perdiendo su tiempo y el dinero de su empleador, simple y llanamente. Pero si está construyendo naves espaciales o dispositivos médicos o si es una tienda principal que no tiene los recursos para un departamento de control de calidad, muchas pruebas unitarias pueden ahorrarle mucho tiempo, dinero y/o vidas. .
test-first no se trata de pruebas unitarias. Se trata de una metodología de diseño llamada TDD (o BDD para algunos). – Oded
Test everything that could possibly break.
Por supuesto, debe probar sus operaciones CRUD especialmente si tiene una aplicación orientada a datos. Y desde mi experiencia ese tipo de pruebas son muy útiles, porque pueden detectar muchos errores en las asignaciones, lógica de procedimientos almacenados, errores en el modelo de datos, datos incorrectos, etc.
Entonces, por lo que entiendo por estas respuestas, no debe probar la base de datos de lectura/escritura de la base de datos. Debería probar el código de lógica de negocios. – foreyez
Pruebe todo lo que pueda romperse. Este es el sentido común. –