visual studio 2008 - visual - En TDD, ¿cuál es la ventaja de ejecutar las pruebas incluso antes de escribir un método vacío?
vscode spell (14)
Creo que usar una herramienta como Resharper te ayudará a tener una mejor idea de TDD. Ciertamente lo hizo por mí.
Esto se debe a que puede autogenerar muchas de las clases / métodos vacíos que necesita anular a medida que los escribe. Esto ayuda a no interrumpir el flujo mientras piensas cómo debe ejecutarse una prueba y cómo debe funcionar la clase / método que estás probando.
Veo muchos practicantes de TDD siguiendo este ciclo:
1) Escribe tu prueba como si los objetos de destino y la API ya existieran.
2) Compile la solución y vea cómo se rompe.
3) Escribe el código justo para que compile.
4) Ejecute la prueba y vea si falla.
5) Escribe el código suficiente para que pase.
6) Ejecute la prueba y véala pasar
7) Refactor
¿Cuál es la ventaja de los pasos 1 y 2? Con IDEs como Visual Studio esto es realmente molesto, ya que Intellisense salta por todos lados intentando adivinar métodos y atributos que no están ahí.
Normalmente comienzo en el paso 3, teniendo todos mis métodos lanzando NotImplementedException, y esto parece perfectamente bien para mí, pero tal vez me falta algo.
Edite para aclarar : esta no es una pregunta de por qué debería ver una prueba fallar antes de que pase; eso está cubierto en el paso 3 en adelante, y tiene mucho sentido. Mi pregunta es por qué incluso antes de eso la gente llamará a un método en la prueba unitaria que no existe en la API (por lo tanto, VS mostrará un garabato rojo, o pintará todo el nombre rojo, etc.) e intentará compilar de todos modos. Para mí, el hecho de que VS me esté diciendo que el método no existe es lo suficientemente bueno.
El flujo de trabajo en Eclipse con JUnit (a diferencia de Visual Studio con MSTest) es donde los pasos 1-3 tienen más sentido. El paso 3 es simplemente usar la funcionalidad de corrección rápida de Eclipse (Ctrl-1) para generar el código de código auxiliar basado en la prueba de unidad que acaba de escribir.
DoesntExistYet someObject = new DoesntExistYet ();
int result = someObject.newMethod ("123");
assertEquals (123, resultado);
La solución rápida para la primera línea creará automáticamente la clase DoesntExistYet (permitiéndole pasar primero por un asistente para modificarla) y la próxima solución rápida creará newMethod para usted, calculando la firma de acuerdo con la forma en que la utilizó.
Entonces, con toda esa automatización que hace las cosas más fáciles, pasas a las otras ventajas que las personas han mencionado sobre poder especificar tu API según cómo la usarías.
El peligro aquí es que presupuesas tu API al escribir la primera prueba. Un truco es pensar en la primera prueba, tal vez escribirla en papel o, al menos, fuera de VS antes de comenzar a escribir el código. Una vez que conozca los métodos que necesitará la API, puede continuar con el paso 3 y luego retroceder (con respecto a VS) al paso 1 y escribir la prueba real.
Confieso que normalmente hago la mayor parte de esto en mi cabeza y comienzo también con el paso (3).
En cuanto al soporte de Visual Studio para TDD, estoy de acuerdo en que Intellisense a veces se interpondrá en el camino, pero en realidad puedes usar VS para TDD aunque todavía es algo limitado. Si el método de prueba se refiere a un método no existente en la clase bajo prueba, puede hacer que VS cree un apéndice para usted presionando Ctrl-K, Ctrl-M.
Desafortunadamente, esto no funciona para las propiedades en VS2008, pero por lo que puedo decir de las notas para VS2010 hay muchas mejoras en esta área en la próxima versión.
Luego pruébelo escribiendo primero el nombre del método. Primero, al escribir la prueba y los métodos, me obliga a pensar realmente en la API, y puedo cambiar fácilmente los nombres sin tener que preocuparme por el código que ya se ha escrito. Mi sugerencia sería tratar de no seguir las reglas y controlar lo que sucede. Si encuentra que causa problemas, vuelva a encenderlo. Y si no es así, ahora tienes una nueva forma de trabajar.
Recuerde también que cuando recién está aprendiendo cosas, generalmente necesita un conjunto claro de reglas para darle contexto. A medida que empiece a pasar de Principiante a más avanzado, obtendrá más contexto y podrá realizar ajustes. Me parece que es donde estás.
Recuerde, primero, que el ciclo básico es rojo-verde-refactor. Por lo tanto, hacer que el código no se pueda compilar no es parte del ciclo principal de TDD. Habiendo dicho eso, como lo han señalado varias personas, es útil considerar la API en términos de la prueba que se está construyendo, y es ahí donde sus dos primeros pasos tienden a ser independientes. Si escribe la API de la manera que desea que funcione para simplificar su prueba, es mucho más probable que sea un consumidor feliz de la clase bajo prueba.
Soy un profesional de TDD y creo que tu forma de hacerlo está bien. Ver que la prueba falla es la parte importante, no ver el código no compilar.
Pruebe esto como una secuencia revisada:
1) Escriba su prueba dentro de un comentario como si ya existieran los objetos de destino y la API.
2) Escribe solo el código API suficiente para compilar.
3) Descomente su código de prueba.
4) Ejecute la prueba y vea que falla.
5) Escribe el código suficiente para que pase.
6) Ejecute la prueba y véala pasar
7) Enjuague y repita ...
De esta forma, usted todavía obtiene el beneficio de pensar primero en la prueba, en lugar de en la implementación.
Veo que muchas personas que responden a esta pregunta tienen un fondo de Visual Studio. He usado VS y tuve problemas con los primeros dos pasos de TDD.
Si utiliza IDE de edición de código más potentes, como lo que tiene en Java (Eclipse, Netbeans, IntelliJ), los primeros dos pasos tienen más sentido. Las soluciones rápidas y las instalaciones de generación de código disponibles allí, hacen que escribir una prueba en contra de una clase o método inexistente sea la forma más rápida de crear esa clase en particular o declarar ese método en particular; solo puede presionar un botón, y la clase o método que falta se genera para usted. Escribir una convocatoria de método o instanciación de objeto es más rápido que crear primero la clase o el método y luego usarlos. Una vez que ha llamado a un método, por ejemplo, el nombre del método y los tipos de parámetros indican la firma del método, por lo que es fácil para el IDE crearlos. Este es realmente un proceso maravilloso, y no lo programaría de otra manera. Combine esto con las ventajas de trabajar realmente con la API antes de que exista, su forma descrita de realizar TDD tiene mucho sentido.
Lo que estoy afirmando aquí también es cierto en los lenguajes dinámicos en los que tradicionalmente no se obtendrán errores de compilación en el IDE por falta de clases o métodos. La prueba fallará, dándole la barra roja.
Para los usuarios de Visual Studio, si desea compartir esta experiencia, instale el complemento Resharper para Visual Studio. Esto le dará muchas de las mismas características que están disponibles en los IDEs de Java.
escribir las pruebas primero te obliga a decidir sobre las interfaces
eso es todo.
¡pero eso es suficiente! las interfaces son el cuadro dentro del cual debe codificar; ignórelos y solo comience a codificar, y a menudo tiene que volver a trabajar antes de poder usarlo
EDITAR: realmente debería leer la pregunta con más cuidado, el OP estaba buscando una respuesta más específica. Aquí está: omita el paso 2 en Visual Studio, colóquese los métodos / clases en su lugar. No hay razón para ser pedante sobre seguir esta receta extendida cuando claramente no es necesario con las herramientas que uno está usando.
Esto no es Desarrollo basado en pruebas del libro . El proceso TDD "oficial" , como se describe en Beck '''' Desarrollo basado en pruebas: por ejemplo '''' es el siguiente:
- Agregue rápidamente una prueba
- Ejecute todas las pruebas y vea que la nueva falla
- hacer un pequeño cambio
- Ejecute las pruebas y vea que todas tienen éxito
- Refactor para eliminar la duplicación
En lo que a mí respecta, "ver un garabato rojo" == el compilador falló. Recuerde que los manifiestos unit test / TDD originales se escribieron sin IDEs en mente. Los IDEs buenos eran muy raros en el mundo de Java en aquel entonces, y como otros han notado, los lenguajes dinámicos todavía no pueden determinar que un método no exista en tiempo de compilación, punto.
Si usa una combinación de IDE / IDE que muestra errores de compilación inmediatamente, esto cuenta como un ciclo de compilación fallido.
Creo que a todos les falta un punto crítico: ¿cómo SABES que el método deseado aún no existe? Al escribir una prueba unitaria que invoca un método que aún no debería existir, al ver que falla, verifica que su suposición es cierta. En un lenguaje compilado, no debe compilarse. En un lenguaje no compilado, la ejecución fallida puede ser mucho más rápida que verificar la API. En la mayoría de los lenguajes, la herencia y el polimorfismo pueden dar como resultado la presencia de un método que no se registró en su modelo mental de la API.
En raras ocasiones, puede descubrir que el método realmente existe (e IntelliSense también puede ayudarlo a detectarlo), y puede darse cuenta de que debe modificar la firma de su método deseado. O incluso puede descubrir que no necesita escribir ese método en absoluto (tal vez lo escribió la semana pasada, pero lo olvidó).
Ciertamente, puede optar por omitir esos dos primeros pasos, o incluso prescindir de TDD por completo, pero esos pasos sí tienen un propósito. Sin embargo, estoy de acuerdo con el sentimiento general de que siempre podemos beneficiarnos de una mayor descripción de los fundamentos de tales pasos en cualquier "mejor práctica".
EDITAR: De Justin Standard ...
O si trabaja en un equipo de desarrolladores y no escribió personalmente el código en el que confía. Creo que es un escenario bastante común para la mayoría de los desarrolladores.
EDITAR: Desde senfo ...
Si tiene problemas para realizar un seguimiento de los métodos que se han implementado en las clases base, me parece que su jerarquía de herencia es demasiado compleja. Todavía te voté porque estoy de acuerdo en que dedico más tiempo a verificar que un método no exista si empiezo con la prueba unitaria.
@senfo: Demasiada complejidad en la jerarquía de herencia ciertamente puede ocurrir, pero ese es un problema diferente con una solución obvia. Incluso si su código actual es perfecto, aún es valioso comenzar con una prueba unitaria que intenta invocar un método posiblemente inexistente, solo para demostrar rápidamente que no existe. Por supuesto, omitir ese paso es comprensible; podría volver a él en una situación específica en la que mi prueba se comporta mal (para verificar en esa situación particular que no estoy invocando algo diferente a lo que acabo de escribir).
Verlo romper garantiza que no ha cometido un error en su código de prueba y ha desarrollado una prueba de trabajo desde el principio.
Además, intentar "usar" una API te hace pensar en ello desde una perspectiva diferente (la del usuario de la API), que casi siempre es beneficiosa. Es importante hacer esto antes de intentar escribir la API (que siempre será desde la perspectiva de un diseñador de API). Es difícil explicar el valor de usar sus propias API, pero el término de la industria es alimentar a los perros .
Estoy de acuerdo con los otros encuestados, creo que esto es solo gente que es ingenua tratando de hacer lo "correcto" sin pensar. Escucharon en alguna parte que debes escribir tus pruebas antes de escribir cualquier código, y lo hacen literalmente e intentan compilar por alguna razón.
Esto está relacionado con esta respuesta a otra pregunta . ¡Usa tu cabeza primero! Esa es la mejor práctica.