Podrían las pruebas de unidad de modelo ser verdaderamente independientes y cómo [ASP.NET MVC]

Question

Soy nuevo en la prueba de unidad, así que discúlpeme por mi falta de experiencia. He leído muchos materiales que dicen que ninguna prueba debería depender de otros, es decir, que las pruebas unitarias sean completamente independientes entre sí. ¿Realmente puedes hacer eso en realidad? Tengo el siguiente ejemplo: tengo unas pocas clases de entidad que dependen unas de otras, basadas en un determinado esquema de base de datos (estoy usando Linq-to SQL para generarlas) Ahora, si quiero probar cada clase de modelo, tengo que construir un objeto de la clase de modelo, construya un objeto de prueba de cada una de sus dependencias, asígnelas a las propiedades del objeto y luego persista el objeto antes de verificar el contexto y de afirmar que realmente funciona.

Esto, obviamente, hace que sea mucho más difícil hacer pruebas que no dependen unas de otras o no se ejecutan en una secuencia específica (no hago una instancia de tipo Content antes de tener al menos una instancia de tipo ContentType) La dependencia, al menos a nivel de modelo, está presente y no se puede evitar.

Por favor, critíquenme mucho, si piensan que estoy equivocado. Quiero aprender.

P.S. Solo mencionar que estoy trabajando en una aplicación ASP.NET MVC y probando con NUnit si tiene sentido

Answer 1

Sí, la prueba unitaria debe (y puede) ser independiente. El problema que describes es sobre la dependencia. La dependencia se debe resolver usando marcos de inyección de dependencia (ver AutoFac, proyectos de Ninject).

La otra cosa es que su base de datos debe ser burlada utilizando objetos simulados (vea Moq, proyectos de Rhino Mocks). Debe probar todo su código incluso si su base de datos está desconectada.

Otra cosa es que la prueba de unidad debe probar solo una funcionalidad, no todo su proceso.

Answer 2

Lo que aquí se describe no son pruebas unitarias sino prueba de integración. Debido a que el modelo de datos de su aplicación está estrechamente relacionado con la base de datos, sus pruebas probablemente prueben la funcionalidad de la base de datos y no el "modelo de datos".

Esto está perfectamente bien, solo tenga en cuenta que las pruebas de integración necesitan configuración (en su base de datos) y tardan más en ejecutarse.

Probablemente también tenga pruebas unitarias para sus controladores que puedan aislarse por completo de otros componentes y no necesite ejecutar la base de datos, estas son las pruebas unitarias de las que habla.

Si no prueba la funcionalidad actual de la base de datos, puede usar el objeto falso/falso para reemplazar las clases externas; de hecho, las pruebas creadas con el proyecto inicial MVC tienen objetos falsos enrollados a mano que hacen exactamente eso.

Otra forma de "aislar" sus dependencias externas es deformar el código de Linq2Sql con su propia clase y falsificar estas llamadas de clase utilizando el marco de Mocking.

Answer 3

Si, realmente puede hacer esto en la realidad.

La clave para poder aislar cada unidad es escribir ligeramente acoplado código. Tomar una dependencia de las clases de LINQ a SQL (L2S) no está débilmente acoplado, lo que explica sus problemas.

Será mejor que defina un conjunto de interfaces detrás del cual puede ocultar su código L2S. El Modelo de Dominio luego trabaja en esas interfaces en lugar de directamente en las clases de L2S.