SUPER COOOOL!!! buenisimo. 2011/3/16 Bruno (Foros) <[email protected]>
> No me puteen si tiro un bolazo, pero intenté hacer un mock de > ISessionFactory y se me complicó bastante (sobretodo porque no tengo mucha > experiencia en Rhino mocks), así que terminé realizando los test con una db > de SQLite en memoria, y funciona joya. Lo único que como es una DB en > memoria tenés que crear la conexión manualmente y pasársela al método > OpenSession(). > > Bruno. > > El 16 de marzo de 2011 14:35, Walter Poch <[email protected]>escribió: > > ->"chica", es decir de soporte no del tipo Line-of-business >> >> Creo que fui más o menos claro, la típica aplicación que sabes que no se >> va a cambiar de acá a un buen tiempo, capaz yo salgo poco y hago cosas >> "chicas". Es la aplicación para el kiosco de la tia porota, o la que te >> piden para el departamento de objetos perdidos... >> >> El 16 de marzo de 2011 14:27, Fabio Maulo <[email protected]>escribió: >> >> que será una applicacción "chica", bah?!?... salgo tan poco... >>> >>> 2011/3/16 Walter Poch <[email protected]> >>> >>>> Si es una aplicación "chica", es decir de soporte no del tipo >>>> Line-of-business yo no me enojo poniendo las cosas en el controller, y ni >>>> me >>>> calentaría en migrarla a otra tecnología a menos que me lo pidan o quiera. >>>> >>>> Ahora si, en las apps estratégicas, creo que en el 80% de los casos >>>> usaría algo más elaborado. Generalmente eso más elaborado son servicios que >>>> encapsulan el negocio, por si el día de mañana migro de tecnología o >>>> aparecen sistemas nuevos que consumen ciertas partes, etc... >>>> >>>> Desde el punto de vista de un peón de albañil ;) >>>> >>>> El 16 de marzo de 2011 13:29, Diego Mijelshon >>>> <[email protected]>escribió: >>>> >>>> Confirma lo que decía... en este caso, ese layer adicional agrega valor >>>>> (la posibilidad _REAL_ de cambiar de entorno). >>>>> >>>>> Diego >>>>> >>>>> >>>>> 2011/3/16 Fabio Maulo <[email protected]> >>>>> >>>>>> No creo que a todos los pragmayicos nos guste testear y ver logica de >>>>>> negocio en el Controler. >>>>>> Nosotros pasamos desde una app. WebForm (en Azure) a una app. MVC2 >>>>>> (ahora MVC3) agregando lo que MVC2 necesitaba pero sin tocar la API del >>>>>> business. >>>>>> >>>>>> >>>>>> 2011/3/16 Walter Poch <[email protected]> >>>>>> >>>>>>> "El software es para pragmáticos.", lástima que muchos por ahí nos >>>>>>> perdemos en el camino =)... llegué al punto de poner este wallpaper de >>>>>>> fondo:http://vs2010wallpapers.com/post/1517977545/keep-it-simple , y >>>>>>> algunos compañeros me lo copiaron. >>>>>>> >>>>>>> Saludos, >>>>>>> >>>>>>> El 16 de marzo de 2011 11:58, Diego Mijelshon < >>>>>>> [email protected]> escribió: >>>>>>> >>>>>>> Coincido con José, y agrego algo similar a lo que comenté en el post >>>>>>>> de Oren: el criterio para introducir o retirar layers y abstracciones >>>>>>>> tiene >>>>>>>> que ver con el valor agregado de los mismos. >>>>>>>> Si realmente ayudan a aumentar la productividad y mantenibilidad: a >>>>>>>> ponerlos. Si hacen dificil lo sencillo, a sacarlos. >>>>>>>> Esto aplica en realidad a todos los artifacts del sistema, desde las >>>>>>>> especificaciones de más alto nivel hasta el detalle más pequeño de >>>>>>>> implementación. El software es para pragmáticos. >>>>>>>> >>>>>>>> Diego >>>>>>>> >>>>>>>> >>>>>>>> 2011/3/16 José F. Romaniello <[email protected]> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> El 16 de marzo de 2011 09:49, Walter Poch >>>>>>>>> <[email protected]>escribió: >>>>>>>>> >>>>>>>>> Mmmm... lo que propones es usar una "Specification" pero más >>>>>>>>>> acotado según veo, que no tenga un filtro sino que directamente >>>>>>>>>> devuelva el >>>>>>>>>> resultado. >>>>>>>>> >>>>>>>>> >>>>>>>>> Llamalo como quieras... Fabio escribió un post de esto y lo llamo >>>>>>>>> EQO. >>>>>>>>> >>>>>>>>> >>>>>>>>> Si uso NHibernate en el controller entonces la que queda es >>>>>>>>>> mandarle un DB de test y hacer test de integración directamente. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Mi opinión sobre esto, es la misma desde hace un año. Esa >>>>>>>>> separación entre test de integración y unitario es extremadamente >>>>>>>>> arbitraria >>>>>>>>> e inutil. >>>>>>>>> Los tests son especificaciones, si para llevar a cabo una >>>>>>>>> especificación necesitas: >>>>>>>>> -Un *"doble" de test*; sea un mock, stub o hasta un doble que vos >>>>>>>>> escribas manualmente (cuando me refiero a doble, es con el >>>>>>>>> significado de >>>>>>>>> sustituto) *esta todo bien* >>>>>>>>> -Un *objeto real* esta todo bien. >>>>>>>>> -Usar *la base de datos*, esta todo bien. >>>>>>>>> -Si necesitas *mezclar*, esta todo bien. >>>>>>>>> >>>>>>>>> La única separación que tiene un poco de utilidad cuando a tests se >>>>>>>>> refiere es en tests lentos y rápidos.. Y hasta por ahí nomas. >>>>>>>>> >>>>>>>>> Vos sos el director y el productor de una película que tiene que >>>>>>>>> especificar cierta "escena".. Usa los elemento que sea para que en la >>>>>>>>> película quede bien :) >>>>>>>>> >>>>>>>>> Roy Oshervore dice que un test unitario tiene que ser: >>>>>>>>> >>>>>>>>> - It should be automated and repeatable. >>>>>>>>> - It should be easy to implement. >>>>>>>>> - Once it’s written, it should remain for future use. >>>>>>>>> - Anyone should be able to run it. >>>>>>>>> - It should run at the push of a button. >>>>>>>>> - It should run quickly. >>>>>>>>> >>>>>>>>> No dice nunca; "tiene que estar basado en dobles" tampoco dice "no >>>>>>>>> tiene que usar la base de datos". >>>>>>>>> >>>>>>>>> >>>>>>>>> Saco esto, porque he visto Rails, y ellos no usan tanta >>>>>>>>>> parafernalia para sus controllers y aplicaciones. De las >>>>>>>>>> aplicaciones que >>>>>>>>>> estoy haciendo creo que una el Home Banking merece una arquitectura >>>>>>>>>> grande, >>>>>>>>>> las demás como dice Ayende, es complicar las cosas. >>>>>>>>> >>>>>>>>> >>>>>>>>> Si, la gente de Rails se rie cuando escuchan la palabra >>>>>>>>> "enterprise" en alguna conversación... >>>>>>>>> Creo que todo tiene mucho que ver con como se construye la >>>>>>>>> arquitectura de un sistema, lo mejor sería que el diseño a grandes >>>>>>>>> rasgos >>>>>>>>> evolucione desde tests y refactorizaciones. >>>>>>>>> Aunque también estos es discutible, hay quienes van a venir a decir >>>>>>>>> "yo hice 40 aplicaciones mas o menos parecidas, y se que tengo que >>>>>>>>> tener un >>>>>>>>> proyecto de dominio y otro de repositorios" >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Para escribir al Grupo, hágalo a esta dirección: >>>>>>>>> [email protected] >>>>>>>>> Para más, visite: >>>>>>>>> http://groups.google.com/group/NHibernate-Hispano >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Para escribir al Grupo, hágalo a esta dirección: >>>>>>>> [email protected] >>>>>>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Saludos, >>>>>>> >>>>>>> Walter G. Poch >>>>>>> Sr. .Net Developer >>>>>>> -------------------------------------------- >>>>>>> Cell: +54 (9 341) 3353273 >>>>>>> [email protected] >>>>>>> >>>>>>> -- >>>>>>> Para escribir al Grupo, hágalo a esta dirección: >>>>>>> [email protected] >>>>>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Fabio Maulo >>>>>> >>>>>> -- >>>>>> Para escribir al Grupo, hágalo a esta dirección: >>>>>> [email protected] >>>>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>>>>> >>>>> >>>>> -- >>>>> Para escribir al Grupo, hágalo a esta dirección: >>>>> [email protected] >>>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>>>> >>>> >>>> >>>> >>>> -- >>>> Saludos, >>>> >>>> Walter G. Poch >>>> Sr. .Net Developer >>>> -------------------------------------------- >>>> Cell: +54 (9 341) 3353273 >>>> [email protected] >>>> >>>> -- >>>> Para escribir al Grupo, hágalo a esta dirección: >>>> [email protected] >>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>>> >>> >>> >>> >>> -- >>> Fabio Maulo >>> >>> -- >>> Para escribir al Grupo, hágalo a esta dirección: >>> [email protected] >>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>> >> >> >> >> -- >> Saludos, >> >> Walter G. Poch >> Sr. .Net Developer >> -------------------------------------------- >> Cell: +54 (9 341) 3353273 >> [email protected] >> >> -- >> Para escribir al Grupo, hágalo a esta dirección: >> [email protected] >> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >> > > -- > Para escribir al Grupo, hágalo a esta dirección: > [email protected] > Para más, visite: http://groups.google.com/group/NHibernate-Hispano > -- Fabio Maulo -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
