A partir de TDD - ¿Desafíos? Soluciones? Recomendaciones? [cerrado]

StackOverflow https://stackoverflow.com/questions/24965

Pregunta

Bien, sé que ya ha habido preguntas sobre comenzando con TDD .. Sin embargo, creo que sé que el consenso general es simplemente hacerlo , Sin embargo, parece que tengo los siguientes problemas para obtener mi Entra en el juego:

  • Al trabajar con colecciones, do todavía probará si se han agregado / eliminados / inserciones obvias con éxito, incluso cuando se basan en Genéricos, etc., donde " know " va a funcionar?
  • Algunas pruebas parecen tardar una eternidad en implementarse. Por ejemplo, cuando se trabaja con salida de cadena, ¿hay un " mejor " manera de ir sobre este tipo de cosas? (por ejemplo, pruebe el modelo de objetos antes de analizar, divida el análisis en pequeñas operaciones y pruebe allí) En mi mente, siempre debe probar el " resultado final " pero eso puede variar enormemente y ser tedioso de configurar.
  • No tengo un marco de prueba para usar (el trabajo no paga por uno), así que puedo "practicar" Más. ¿Hay algunos buenos que sean gratuitos para uso comercial? (en este momento estoy usando good 'ol Debug.Assert :)
  • Probablemente el más grande ... A veces no sé qué esperar de NO . Quiero decir, obtienes tu luz verde, pero siempre me preocupa que me esté perdiendo una prueba. ¿Cava más profundo para intentar descifrar el código, o lo deja y espera a que todo se caiga más tarde (lo que costará más)?

Entonces, básicamente, lo que estoy buscando aquí no es un " hazlo " pero más '' Hice esto, tuve problemas con esto, lo resolví con este " .. La experiencia personal :)

¿Fue útil?

Solución

Primero, está bien y es normal sentirse frustrado cuando comienza a intentar usar TDD en su estilo de codificación. Simplemente no se desanime y renuncie, tendrá que darle algo de tiempo. Es un cambio de paradigma importante en cómo pensamos acerca de resolver un problema en el código. Me gusta pensar en ello como cuando pasamos de la programación procesal a la programación orientada a objetos.

En segundo lugar, creo que el desarrollo basado en pruebas es, ante todo, una actividad de diseño que se utiliza para desarrollar el diseño de un componente mediante la creación de una prueba que describe primero la API que expondrá y cómo va a consumir Es funcionalidad. La prueba ayudará a moldear y moldear el Sistema bajo prueba hasta que haya sido capaz de encapsular suficiente funcionalidad para satisfacer cualquier tarea en la que esté trabajando.

Teniendo en cuenta el párrafo anterior, veamos sus preguntas:

  1. Si estoy usando una colección en mi sistema bajo prueba, configuraré una expectativa para asegurarme de que se haya llamado al código para insertar el elemento y luego afirmar el recuento de la colección. No necesariamente pruebo el método Agregar en mi lista interna. Solo me aseguro de que se haya llamado cuando se llame al método que agrega el elemento. Hago esto agregando un marco burlón en la mezcla, con mi marco de prueba.
  2. Probar cadenas como salida puede ser tedioso. No puedes dar cuenta de todos los resultados. Solo puede probar lo que espera en función de la funcionalidad del sistema bajo prueba. Siempre debe dividir sus pruebas en el elemento más pequeño que está probando. Lo que significa que tendrá muchas pruebas, pero las pruebas son pequeñas y rápidas y solo prueban lo que deberían, nada más.
  3. Hay muchos marcos de prueba de código abierto para elegir. No voy a discutir cuál es el mejor. Solo encuentra uno que te guste y comienza a usarlo.
  4. Todo lo que puede hacer es configurar sus pruebas para dar cuenta de lo que quiere que suceda. Si surge un escenario que introduce un error en su funcionalidad, al menos tiene una prueba alrededor de la funcionalidad para agregar ese escenario a la prueba y luego cambiar su funcionalidad hasta que pase la prueba. Una forma de encontrar dónde nos hemos perdido una prueba es usar cobertura de código .

Le presenté el término de burla en la respuesta a la pregunta uno. Cuando introduce burlas en su arsenal para TDD, hace que las pruebas sean más fáciles de extraer de las partes que no forman parte del sistema bajo prueba. Aquí hay algunos recursos sobre los marcos de burla que hay:

Una forma de ayudar en el uso de TDD, además de leer sobre el proceso, es observar a las personas hacerlo. Recomiendo ver las transmisiones de pantalla de JP Boodhoo en DNRTV . Echa un vistazo a estos:

Bien, estos te ayudarán a ver cómo se usan los términos que introduje. También presentará otra herramienta llamada Resharper y cómo puede facilitar el proceso TDD. No podría recomendar esta herramienta lo suficiente al hacer TDD. Parece que está aprendiendo el proceso y está encontrando algunos de los problemas que ya se han resuelto con el uso de otras herramientas.

Creo que estaría haciendo una injusticia a la comunidad, si no actualizara esto agregando la nueva serie de Kent Beck en Desarrollo guiado por pruebas en programador pragmático .

Otros consejos

Desde mi propia experiencia:

  1. Pruebe solo su propio código, no el código del marco subyacente. Entonces, si está utilizando una lista genérica, no es necesario probar Agregar, Eliminar, etc.

  2. No hay 2. ¡Mira hacia allá! Monos !!!

  3. NUnit es el camino a seguir.

  4. Definitivamente no puedes probar todos los resultados. Pruebo lo que espero que suceda, y luego pruebo algunos casos extremos en los que espero obtener excepciones o respuestas no válidas. Si un error aparece en la pista debido a algo que olvidó probar, lo primero que debe hacer (antes de intentar solucionarlo) es escribir una prueba para demostrar que el error existe.

Mi opinión sobre esto es la siguiente:

  • +1 para no probar el código del marco, pero es posible que aún deba probar las clases derivadas de las clases del marco.
  • Si alguna clase / método es difícil de probar, puede ser una fuerte indicación de que hay algún problema con el diseño. Intento seguir " 1 clase - 1 responsabilidad, 1 método - 1 acción " principio. De esa manera, podrás probar métodos complejos de manera mucho más fácil si lo haces en porciones más pequeñas.
  • +1 para xUnit. Para Java, también puede considerar TestNG .
  • TDD no es un evento único, es un proceso. Por lo tanto, no intente imaginar todo desde el principio, pero asegúrese de que cada error que se encuentre en el código esté cubierto por una prueba que se haya descubierto.

Creo que lo más importante (y, en realidad, uno de los grandes resultados de TDD) es el manejo exitoso de las dependencias. Debe asegurarse de que los módulos se prueben de forma aislada sin que sea necesaria una configuración detallada. Por ejemplo, si está probando un componente que finalmente envía un correo electrónico, haga que el remitente del correo electrónico sea una dependencia para que pueda burlarse de él en sus pruebas. Esto lleva a un segundo punto: los simulacros son tus amigos. Familiarícese con los marcos burlones y el estilo de las pruebas que promueven (comportamiento, a diferencia del estado clásico) y las opciones de diseño que fomentan (The " Diga, no pregunte " principio).

Encontré que los principios ilustrados en Tres tarjetas de índice para recordar fácilmente la esencia de TDD es una buena guía.

De todos modos, para responder a tus preguntas

  1. No tiene que probar algo que " sepa " va a funcionar, a menos que lo escribas. No escribiste genéricos, Microsoft lo hizo;)
  2. Si necesita hacer mucho por su prueba, quizás su objeto / método también esté haciendo demasiado.
  3. Descargue TestDriven.NET para iniciar de inmediato las pruebas unitarias en su Visual Studio, (excepto si es una edición Express)
  4. Solo prueba la cosa correcta que sucederá . No necesita para probar todo lo que puede salir mal: tiene que esperar a que sus pruebas fallen para eso.

En serio, solo hazlo, amigo. :)

No soy un experto en TDD, de ninguna manera, pero aquí está mi opinión:

  • Si es completamente trivial (getters / setters, etc.) no lo pruebe, a menos que no tenga confianza en el código por alguna razón.
  • Si es un método bastante simple, pero no trivial, pruébelo. La prueba es probablemente fácil de escribir de todos modos.
  • Cuando se trata de qué esperar que no suceda, diría que si cierto problema potencial es responsabilidad de la clase que está probando, debe probar que lo maneja correctamente. Si no es responsabilidad de la clase actual, no lo pruebe.

Los marcos de prueba de xUnit a menudo son de uso gratuito, así que si eres un tipo .Net, echa un vistazo a NUnit, y si lo tuyo es Java, echa un vistazo a JUnit.

El consejo anterior es bueno, y si quieres una lista de marcos libres, no debes buscar más que xUnit Frameworks List en Wikipedia. Espero que esto ayude :)

En mi opinión (su kilometraje puede variar):

1- Si no lo escribiste, no lo pruebes. Si lo escribió y no tiene una prueba, no existe.

3- Como todos han dicho, xUnit es gratis y genial.

2 & amp; 4- Decidir exactamente qué probar es una de esas cosas sobre las que puedes debatir contigo mismo para siempre. Intento dibujar esta línea siguiendo los principios de diseño por contrato. Echa un vistazo a 'Construcción de software orientado a objetos " o " El programador pragmático " para más detalles al respecto.

Mantener las pruebas cortas, " atómicas " ;. Pruebe la suposición más pequeña en cada prueba. Haga que cada TestMethod sea independiente, para las pruebas de integración incluso creo una nueva base de datos para cada método. Si necesita compilar algunos datos para cada prueba, use un " Inicio " método. Use simulacros para aislar la clase de sus pruebas de sus dependencias.

Siempre pienso "¿cuál es la cantidad mínima de código que necesito escribir para probar que esto funciona en todos los casos?"

Durante el último año me he convencido cada vez más de los beneficios de TDD. Las cosas que he aprendido en el camino: 1) la inyección de dependencia es tu amiga. No estoy hablando de inversión de contenedores de control y marcos para ensamblar arquitecturas de plugins, simplemente pasar dependencias al constructor del objeto bajo prueba. Esto devuelve enormes dividendos en la verificabilidad de su código. 2) Me puse en camino con la pasión / fanatismo del converso, agarré un marco burlón y comencé a usar simulacros para todo lo que pude. Esto llevó a pruebas frágiles que requerían mucha configuración dolorosa y se caerían tan pronto como comenzara cualquier refactorización. Utilice el tipo correcto de prueba doble. Falsos donde solo necesita respetar una interfaz, apéndices para devolver datos al objeto bajo prueba, simularse solo cuando le interesa la interacción. 3) La prueba debe ser pequeña. Trate de que una afirmación o interacción se pruebe en cada prueba. Intento hacer esto y sobre todo estoy ahí. Se trata de la robustez del código de prueba y también de la complejidad de una prueba cuando necesita volver a visitarla más adelante.

El mayor problema que he tenido con TDD ha sido trabajar con una especificación de un organismo de estándares y una implementación de terceros de ese estándar que era el estándar de facto. Codifiqué muchas pruebas unitarias realmente agradables de acuerdo con la letra de la especificación, solo para encontrar que la implementación en el otro lado de la cerca consideraba el estándar como un documento de asesoramiento. Jugaron bastante suelto con eso. La única forma de solucionar este problema era probar la implementación, así como las pruebas unitarias y refactorizar las pruebas y el código según sea necesario. El verdadero problema fue la creencia de mi parte de que, mientras tuviera el código y las pruebas de unidad, todo estaba bien. No tan. Debe estar creando resultados reales y realizando pruebas funcionales al mismo tiempo que realiza pruebas unitarias. Pequeños beneficios durante todo el proceso: en manos de usuarios o partes interesadas.

Como una adición a esto, pensé que diría que he puesto un publicación de blog sobre mis pensamientos sobre cómo comenzar con las pruebas (después de esta discusión y mi propia investigación), ya que puede ser útil para las personas que ven este hilo.

" TDD & # 8211; Comenzando con el desarrollo guiado por pruebas " - He recibido excelentes comentarios hasta ahora y agradecería mucho más lo que ustedes tienen para ofrecer.

Espero que esto ayude! :)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top