Jorge Serrano - MVP Visual Developer - Visual Basic

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.

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" :)

blog.james-carr.org/.../tdd-anti-patterns

Personalmente evitar este anti-patrón fue una de las cosas que más me costó en su tiempo!

Un saludo!

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: blog.koalite.com/.../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.