Buenas tardes Carlos. Respondiendo a tus preguntas, te cuento que estoy usando DB First, cuando digo que desde fuera de la capa de acceso a datos, me refiero que no tengo una clara separación de responsabilidades, teniendo consultas a la DB, desde mi capa de presentación al igual que desde mi capa de acceso a datos. Por otro lado entiendo lo que decís de no testear EF ni LinQ, pero en este caso la aplicación depende de cada consulta, cada servicio que la aplicacion expone es básicamente una consulta linq, la cual tiene cierta complejidad y a su vez modificaciones constante, por el tipo de negocio. Con los test quiero estar en cierto modo debugueando mis consultas, y luego asegurarme que cuando esta cambie continué devolviendo los datos ya testeados.
Cesar, tu opción me parece muy buena y es la que siempre tuve en mente y plante. Voy a seguir apostando a esa idea entonces, y haciendo fuerza para que opten por esa forma. Gracias por su ayuda a todos y si tienen alguna info mas que pasarme es bien recibida. El 19 de marzo de 2015, 5:56, Carlos Peix <carlos.p...@gmail.com> escribió: > Hola Mariano, > > Se me ocurre una pregunta: que tipo de código estas probando con esas > pruebas? cual es el código que vos escribís en esa capa de acceso a datos? > > Lo pregunto porque parece que estás usando Entity Framework, pero no decís > como haces los mapeos (code first, entity first, DB First?). Luego decís > que estas usando Linq desde fuera de tu capa de acceso a datos, sospecho > que sobre las colecciones de EF directamente. > > Hay código adicional ademas del mapeo? Si no lo hay, probablemente estas > testeando EF y Linq, cosa que ya está testeada. > > Yo solo escribiría tests sobre el código que escribo, no sobre EF, Linq u > otra cosa. Una vez que definas que código querés testear podemos pensar > como te conviene hacerlo. > > ---------------------------------- > Carlos Peix > > 2015-03-18 12:25 GMT-03:00 Mariano German Villarreal Kuber < > german.ku...@gmail.com>: > >> Buenos días chicos. Estoy teniendo un quilombito a la hora de hacer >> testing. Les cuento que la aplicación en la que trabajo es una aplicación >> puramente centrada en la capa de datos. La lógica de negocio se traduce >> básicamente en consultas Linq. >> >> Ahora el problema particular, es como realizar test. >> >> Al momento por cada test que tengo que crear, debo crear datos dummy, >> insertarlos en la base de datos y luego consumir los metodos que querean >> sobre esa tabla, una vez que el test termino, eliminar los registro de la >> base de datos. >> >> Como lo estoy haciendo ? Tuve que generar un método que se atachee al >> contexto de entity dentro del Initialize del Test, y que cada vez que >> detecte que se agrega o se realiza update, este método guardo los objetos >> en una lista. Y una vez que el test finaliza roolbackea la acción que se >> haya aplicado sobre este objeto. Esto funciona pero al pasar de ambiente y >> como es logico me encuentro que ya hay datos en la base, y que si mis test, >> no los genero con datos muy "raros" (para evitar que por alguna casualidad >> haya otro similar en la db), estos rompen. >> >> Mas alla del trabajo artesanal que tuve que hacer y que desde ya es >> discutible si esta bien o no. Me gustaría saber como testear este tipo de >> aplicaciones. >> >> Para la generación de objetos estoy aplicando el patrón Builder, el cual >> tiene el control total de los objetos a generar en cada Test. >> >> De todos modos, no veo cómodo nada de esto, cada vez que tengo que meter >> un nuevo test es un parto, ni les cuento de modificar. >> >> Espero que se haya comprendido el problema y puedan darme una ayuda. >> >> Saludos. >> > >
