¿Diferencia entre test TDD y test unitarios?

[David Sarzanaula]

Navegando por Internet, encontré un muy polémico articulo: http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests. este fue escrito por Stephen Walther, aquí una reseña según Amazon:

Stephen Walther is a Microsoft Software Legend. He worked as a Program Manager on the ASP.NET team at Microsoft where he was responsible for making the ASP.NET Framework compliant with Web Standards such as XHTML and Accessibility standards.

Through his companies SuperexpertTraining.com and SuperexpertConsulting.com, he has provided consulting and training services for companies across the United States including NASA, the National Science Foundation, Microsoft, Verizon, the US House of Representatives, Boeing, Lockheed Martin, Petco, and The Gap.

En este articulo, el objetivo del autor es mostrar las diferencias entre los test unitarios y los "test TDD" (nombre que el autor usa para referirse a los tipos de test usados en TDD). Considero este articulo como polémico debido a que genero un acalorado debate entre el autor y algunos reconocidos profesionales como: Russ Nemhauser, Rob Conery y Brad Wilson.

El principal motivo del debate es que el autor menciona que un "test de TDD" a diferencia de un test unitario, puede probar más de una unidad de código al mismo tiempo, es decir pueden intervenir más de 1 clase:

"A TDD test, unlike a unit test, might test more than a single unit of code at a time.

As the design of your application evolves, code that was originally contained in one class might end up in multiple classes. Unlike a unit test, A TDD test can test code that spans multiple classes."

 

Para dicha afirmación el autor se basa en su experiencia, ademas de citar una conversación de Martin Flower http://www.artima.com/intv/testdriven4.html

Pero tanto Nemhauser como Conery y Wilson, intentan contradecir al autor mencionando que los test de TDD solo deben probar una unidad de código, y si la clase que esta siendo probada se comunica con otras clases, se debe usar Stubs y Mocks. Esto con el fin de evitar un código frágil, además de poder encontrar los errores más fácilmente. 

Ese debate me motivo a investigar por otras ideas y perspectivas acerca de los test  unitarios, y encontré algunas definiciones: 

A unit test is an automated piece of code that invokes the method or class being tested and then checks some assumptions about the logical behavior of that method or class. A unit test is almost always written using a unit-testing framework. It can be written easily and runs quickly. It’s fully automated, trustworthy, readable, and maintainable.

 

❂ 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.

                                                                                    The art of unit testing - 

En esta definición no nos menciona nada acerca del uso obligatorio de stubs o mocks. 

Otro punto a tener en cuenta es que Nemhauser, Conery y Wilson están de acuerdo en que hacer solo test unitarios no significa que se haga TDD, pero ellos consideran que los test de TDD y los test unitarios vienen a ser los mismo, por lo tanto no aceptan la propuesta del autor del articulo de crear una categoría de test llamada "test de TDD".

 

Sin embargo si nos dirigimos a la web http://www.extremeprogramming.org/rules/unittests.html, veremos que hay en el primer parrafo explicitamente mencionan que los test de TDD no son los mismos que los test unitarios:

Unit tests are one of the corner stones of Extreme Programming (XP). But unit tests XP style is a little different. First you should create or download a unit test framework to be able to create automated unit tests suites. Second you should test all classes in the system. Trivial getter and setter methods are usually omitted. You will also create your tests first, before the code. 

Lo que puedo concluir es que aun no se ha llegado a una definición en común sobre los test de TDD, pero lo curioso es que aquellas personas a pesar de tener un concepto diferente sobre los test son exitosos profesionales, me pregunto ¿que tanto influirá nuestra definición acerca de los test para que tengamos éxito de aplicar TDD en un proyecto?

[Daniel Ceillan]

Hola! 

Yo creo que la diferencia surge del hecho de que estás comparando una técnica con una herramienta. 

Saludos

Daniel Ceillan

http://www.agile-patterns.com

Enviado desde mi iPad

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/4c413c19-f5b5-434e-9fdb-2e2fe4052128%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Alfredo Casado]

El autor mezcla cosas y en su intento de "clarificar" lo que consigue es liarla  de nuevo con la clasificación de tipos de test. 

- Un test será TDD en función del momento y la intención con que se escriba, es TDD si se escribe antes con intención de guiar el diseño.

- Un test será unitario si prueba una clase de forma aislada, de integración si se prueba más de una o necesita de un tercer sistema (bd, ficheros...)

Estas dos cosas son ortogonales, es decir, un test puede ser TDD y unitario y por supuesto también puede ser TDD y de integración. A veces es buena idea hacer test unitarios puros a veces es mejor hacer un test de integración (o mini-integración como dice fowler) donde intervenga un pequeño cluster de objetos, esto dependerá tanto de las características del sistema que este construyendo como de las preferencias que uno tenga a la hora de afrontar TDD. Por ejemplo, el TDD clásico de Beck tiende a probar pequeños clusters de objetos mientras que el london style (maravillosamente explicado en el GOOS) hace test puramente unitarios con mocks. Son estilos distintos, yo a veces uso uno a veces uso otro, son herramientas, en función del problema que tengo puedo elegir uno u otro estilo.

De todos modos, esta clasificación no es tan importante, que un test sea unitario o de mini-integración de tal o de pascual es poco relevante, parece que tengamos una tendencia de ponerle a todo etiquetas por el simple placer de ponerlas. Lo importante cuando escribes un test es que lo hagas con un proposito bien claro (guiar el diseño, probar esto o aquello, servir de regresión), si el test cumple con el proposito para el que fue construido que más dara si es unitario o de mini-integración, no confundamos, como tantas veces, el fin con el medio.

Como dicen en "the way of testivus" (http://cdn.ttgtmedia.com/searchSoftwareQuality/downloads/TheWayOfTestivus.pdf): The test its most importante than the unit. Un articulo que además de estar escrito de forma muy simpatica encierra muchas verdades, me encanta testivus jeje.

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/A3E8740B-90B5-478F-9DA3-5BE873F22443%40gmail.com.

[Pedro Agulló]

¡Fantásticamente bien explicado!

Coincido en que a menudo hay un ansia de clasificar que tiene vida propia, olvidando que the usefulness is more important than the technique, la generalización de "the test is most important than the unit" ;). Así que ¡100% de acuerdo en toda la reflexión!

TDD es siempre positivo en mi opinión, excepto si no es factible o resulta *desorbitadamente* costoso. A veces hay que llegar a compromisos, pero no hay que rendirse sin lucharlo.

Por otro lado el énfasis inicial en los tests unitarios es acertado, siempre que no lleve a poner el carro delante de los caballos. Tiene mucho sentido comenzar por testear las pequeñas cosas que pueden ser verificadas independientemente para que las bases sean sólidas. Si empiezas por testear cosas muy high-level (más raramente unit-testable) no sabrás si el error está en tu nuevo código o en código anterior y más low-level (más comunmente unit-testable): la investigación y corrección tomará más tiempo y tu bucle de realimentación (feedback) será más lento y de menor calidad, y con ello la calidad del resultado final.

Saludos

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/CAJUW-yZpMdqUcoO%3DpPtuLPKL7tK%3Dk4eSXo83GmGSsQ4m9roC-w%40mail.gmail.com.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

--

Website: http://www.softwarementors.com/

Blog: http://softdevbuilttolast.wordpress.com/

[Juan Quijano]

Buensa

Magnífico Alfredo, absolutamente de acuerdo con todo lo que has explicado. Solo quisiera añadir una pregunta y un reflexión a David.

¿Y tu qué piensas?

En tu duda hablas de un motón de autores y opiniones, pero no has puesto tu propia opinión basada en tu experiencia personal en primera persona con el testing.

La reflexión es que en la informática en general, y esta nuestra comunidad Agile en particular, muchas veces se cae en darle demasiada importancia a las opiniones y vivencias de autores reconocidos,  dejando en segundo plano nuestros propios conocimientos. La "libritis" en el mal sentido, cuando se argumenta con las palabras y creencias que se han leído y que no se han comprobado en nuestras propias carnes. Y con el cual intentamos ocultar nuestra ignorancia sobre el tema, bajo contundentes referencias a las palabras de "gurus" fuera de nuestro contexto y realidad.

Eha, ya he soltado la parrafada. ;)

[David Sarzanaula]

Hola Alfredo, lo que ocurre es que estoy en un proceso de aprendizaje de TDD, lo estoy viendo desde hace aproximadamente 1 o 2 meses, en un curso de pregrado de la universidad, actualmente lo estaba aplicando a un proyecto de un curso. Por eso creo que aun no dispongo que la experiencia suficiente como para argumentar opiniones propias, sino cumplir un rol de espectador y tratar de capturar lo mejor de cada autor. Debido a esta falta de experiencia, siempre tomo como referencia los mejores extractos de los libros que he leído.

Particularmente me gustaría dar mis opiniones pero prefiero antes empaparme un poco más con el tema, es muy conocido el refrán "Es mejor callar que tontamente hablar".