Encuesta :: ¿Qué tipo de Framework de Mocks utilizadas para .NET?
Introducción
Me gustaría que la gente interactuara más cuando hablamos de tecnología.
Sé que son muchas las personas que se retroalimentan de información provenientes de blogs, foros, libros, videos, charlas virtuales o físicas en grupos de usuarios, redes sociales, etc., pero muy pocos los que colaboren, unos porque creen que no pueden aportar nada (falso) y otros porque simplemente están más cómodos recogiendo todo el conocimiento e información posible y no compartiéndolo con los demás.
Hace muchos años tuve un portal en Internet que algunos recordarán, denominado Mundo Visual – Visual Basic y posteriormente PortalVB.
En aquellos sitios fomentaba la participación y recuerdo con alegría que sí la había.
En la página principal además, tenía siempre una encuesta que actualizaba cada mes, y la participación era bastante digna, la verdad.
En esta ocasión, me gustaría traer nuevamente a la palestra aquel formato, y hacer de vez en cuando alguna encuesta que creo que puede resultar de interés.
Espero que participeis e incluso propongais otras encuestas, etc.
Evidentemente, también deseo que en los comentarios de esta entrada, pongáis lo que consideréis oportuno.
Un saludo.
Encuesta
Puedes acceder a la encuesta accediendo a este enlace.
P.D.: Disculpadme que he intentado integrar la encuesta en el post pero me ha sido imposible.
13 Responsesso far
La verdad es que, aunque he contestado RhinoMocks, cada vez uso menos mocks y trato de hacer otro tipo de tests.
A veces me acabo haciendo fakes a mano y me resulta más cómodo y más legible. Cuando usaba RhinoMocks acaba haciendo tests demasiado farragosos que no testeaban nada útil.
Yo suelo utilizar RhinoMocks, Moq y Moles para SharePoint.
Un saludo.
Muchas gracias por opinar.
@Juanma, ¿qué recomendarías a un usuario que no ha hecho nunca Mocks?, ¿hacerlos?, ¿no hacerlos?. Y porqué.
En el caso de hacerlos, hacer tus propios fakes a mano o bien utilizar un Framework de Mock Objects.
Me preocupa lo que indicas de «Cuando usaba RhinoMocks acaba haciendo tests demasiado farragosos que no testeaban nada útil».
@Luis, ¿porqué usas Rhino y Moq y no uno sólo de ellos?. Dicen de Moles por otro lado, que no es exactamente Mock, ¿tú consideras a Moles como un «mockeador»?.
Perdonadme que os pregunte, pero puede salir un debate más que interesante. 🙂
Si queréis ver los resultados de una encuesta muy similar de hace casi 5 años, podréis verlos aquí:
http://osherove.com/blog/2007/4/26/choosing-a-mock-object-framework.html
Actualmente uso básicamente Moq.
El comentario de @Juanma me parece extremadamente interesante, ya que creo que describe que lo que suele ocurrir cuando uno empieza a usar un frameworks de Mocks. A medida que vas descubriendo las capacidades del framework te vas «animando» hasta que terminas haciendo pruebas unitarias que testean más el Mock que la funcionalidad en sí. Es un antipatrón conocido en unit testing como «The Mockery» 🙂
http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/
Personalmente evitar este anti-patrón fue una de las cosas que más me costó en su tiempo!
Un saludo!
@Eduard, una vez más, ¡bingo!.
Ahí quería llegar yo Eduard (aunque ya has descubierto el tema y de forma mucho más clara y concreta a como lo hubiera hecho yo).
A ver si @Juanma nos indica su parecer y experiencia al respecto. 🙂
Es cierto, Moles es un framework de Stubs :p pero en el caso de SharePoint no se puede usar otra cosa, aunque tu en la encuesta has puesto TypeMock Isolator y es lo mismo que Moles pero de pago :p
En cuanto a usar Rhino Mocks o Moq, pues empecé usando RhinoMocks y tenego proyectos con ello que no voy a empezar ahora a cambiar los test. cuando probé Moq me moló, con menos líneas de código se hace lo mismo.
Un saludo
Hi people,
yo también uso Moq como framework de Stubs y de Mocks pq me parece muy simple, fácil de usar y encaja con la forma en que concibo los test unitarios.
Personalmente me siento más cómodo con un enfoque de TDD clásico, testeando por estado (siempre que puedas claro) más que por comportamiento. En este sentido Moq me encaja mejor que un framework como RhinoMocks que se basa en el paradigma Record/Reply/Verify y me parece más adecuado para un enfoque de TDD basado en interacciones… Uff, esta discusión sola ya da para otro post entero, ¿no? ¿TDD basado en estado o TDD basado en interacciones?… 😉
También estoy 100% de acuerdo con Eduard, si no estas un poco al loro acabas con unos tests infumables y muy frágiles pq están basados en «expectations» sobre el comportamiento interno del método que testeas.
Un buen debate Jorge!
Saludos!
Hola.
Yo he sido uno de los que han votado que no usa mocks ni tests unitarios (ALAAAAA!!! BRUTOOOOO!!!! QUE FUERTEEEEE!!!! 🙂
Me explico:
Nosotros desarrollamos y mantenemos varias aplicaciones para nuestra propia empresa. («Nosotros» es porque somos 2 en el dpto.)
Cuando sacamos una versión, pasamos una versión «prueba» con bbdd de prueba a nuestro «Servicio técnico nivel 1» para que la testeen, y si nos dan el OK, la pasamos a producción.
Nuestro nivel de calidad en la entrega no es considerado crítico.
Cuando el «nivel 1» nos reporta una incidencia (que aunque les decimos que por escrito, el telefonazo es más efectivo y jode más) , con el dato concreto, trazamos, detectamos y sacamos otra versión. (metodología ágil a la antigua usanza, no?)
He seguido tutoriales y he hecho pruebas sobre el uso de mocks y pruebas unitarias, por lo que tengo hecha una idea de lo que son.
Creo que el modelo de mocking encaja más en productos que se entregan a clientes externos y deben estar 100% testeados, pero para nuestro modelo de trabajo sigo sin verlo claro.
Mi apoyo a este tipo de debates.
Saludos.
@Jorge
Sobre mi recomendación al que nunca ha usado mocks, que los use, sin duda, y que cuando los haya usado decida si le sirven o no. Aunque ahora yo los use cada vez menos, creo que me aportaron *muchísimo* a la hora de empezar con TDD y a la hora de mejorar el diseño de mis programas. ¿Usar framework o no? Al principio yo creo que el framework ayuda, luego con la experiencia y Resharper vas pillándole el punto a los mocks/stubs/fakes manuales.
En cuanto a los test farragosos, va un poco en la línea de lo que dice Eduard. Llegaba un punto en que tenía perfectamente testeada la interacción entre varios componentes… y luego en la vida real no funcionaba nada. A veces no es sencillo capturar con un interface la semántica real de la implementación, y cuando cambias el Mock por la implementación real… se va todo al carajo.
Mi estilo actual se basa en aplicar TDD a la parte de la aplicación que es fácil de testear con tests de estado, y tratar de que el 90% de la aplicación entre en la categoría «fácil de testear con tests de estado». Eso no siempre es sencillo, pero en general los tests que resultan de esa aproximación son mucho más claros y, lo que para mi es más importante, más resistentes a
refactorizaciones internas de las clases, por lo que me sirven más a la hora de evitar introducir errores.
Es un poco lioso de explicar y no quiero alargarme mucho (más) en el comentario, a ver si saco un rato este fin de semana y lo convierto en post, porque la verdad es que el debate es de lo más interesante.
Si alguno se ve con ganas, aquí está la versión extendida de mi comentario: http://blog.koalite.com/2011/10/adios-mocks/
Gran debate !!!
No uso mocks ni pex ni moles, me gustaría meterme a ello, pero la forma en que se desarrollan los proyectos en los que participo lo hace inviable…muy a mi pesar
Saludos
Bueno, aquí estamos, al final me he embarcado en esta aventura que supone todo un reto, y en parte un
Jorge, sigo apoyando este tipo de encuestas y debates. Quizá con Google Docs se podría integrar la encuesta en el mismo post. Saludos.