tipos implícitos y TDD

Question

acabo de leer este publicación y hace que el caso contra el uso de tipos implícitos cuando se inicia con la prueba de desarrollo / diseño impulsado.

Su mensaje dice que TDD puede ser "más lento" cuando se utilizan tipos implícitos para el tipo de retorno cuando la unidad de evaluación de un método. Además, parece que quiere el tipo de retorno especificado por la prueba con el fin de impulsar el desarrollo (que tiene sentido para mí).

Una prueba unitaria dada con tipos implícitos podría tener este aspecto:

public void Test_SomeMethod()
{
    MyClass myClass = new MyClass();

    var result = myClass.MethodUnderTest();
    Assert.AreEqual(someCondition, result);
}

Así que mis preguntas son:

¿El uso de la ayuda tipos implícitos o dificultar las pruebas de unidad de escritura para TDD? ¿Hay alguien por ahí que pueden compartir su experiencia con esta técnica al escribir las pruebas unitarias?

Lo pregunto porque pronto no he hecho TDD y me gustaría saber si hay una manera de escribir pruebas unitarias genéricas o semi-genéricas que trabajarían un tipo de retorno podría cambiar.

Answer 1

Veo su punto, pero realmente no creo que sea la razón correcta de no utilización var aquí. Recuerde, TDD funciona más o menos de acuerdo a lo siguiente:

1. Escribir una nueva prueba.
2. Si la prueba falla al compilar (y debería fallar!), Escribir código suficiente hasta las compilaciones de prueba.
3. ejecutar todas las pruebas.
4. Si una prueba falla, escribir código suficiente hasta que pasan todas las pruebas.
5. Refactor.

Si o no utilizamos var la prueba fallará para compilar cualquier manera ya que el método bajo prueba no existirá aún !. Una vez que empezamos codificar hasta NewMethod sus puntos son bastante discutible.

Por el contrario, la razón correcta de no utilización var aquí es porque el código no indica cuál es el tipo de result es. Esta es una cuestión de opinión, pero var está bien aquí

var dict = new Dictionary<Foo, List<Bar>>();

y para los tipos anónimos pero no aquí

var m = M();

porque es completamente claro sin ir a la declaración de M (o el uso de IntelliSense) lo que el tipo de retorno de M es.

Answer 2

Sí y No

En la actualidad Visual Studio, TDD es un poco de un dolor, especialmente cuando se utiliza la tipificación implícitamente. var significa que no hay intelisense, a continuación, cuando se introduce el nombre de un tipo que puede no existir, sin embargo, tiene la tendencia a auto-completar con algo que es similar a lo que está escribiendo, a menudo el nombre del dispositivo de prueba.

Visual Studio 2010 tiene un consumen primer modo , que lo hace ideal y mejor para el Desarrollo Test Driven. Actualmente podrás encontrar (en 2008 y anteriores) que tiene que golpear escapar para ocultar el intellisense.

En cuanto a la utilización de var es puramente azúcar synatic. Se hace la siguiente mucho mejor en mi opinión:

var type = new MyType();

Está claro que el tipo de variable, es de tipo MyType. var es ideal para los genéricos y sigue el prinicple de DRY - No te repitas

.

var type = MethodCall();

var result = ReturnResult();

Por otro lado, esto lo convierte en difícil de leer el código, si usted sigue TDD o no. pruebas buena unidad deben fluir y ser fáciles de leer. Si usted tiene que pensar, o pasa el ratón sobre un método para ver el tipo de retorno, que es el signo de un mal, difícil de leer la prueba.

Answer 3

Desde el punto de vista de herramientas, yo diría que es más agradable para evitar la var. Yo uso Eclipse y Java, pero sé que extensiones como CodeRush y ReSharper ofrecen muchas de las características que estoy discutiendo aquí. Cuando en mi prueba que llamo un método que no existe todavía, puedo "solución rápida" para crear el método en la clase deseada. El tipo de retorno del método creado automáticamente depende de su contexto; si yo estoy esperando volver una cadena, el tipo de retorno del método será de cadena. Pero si la asignación es un VAR (que Java no tiene - pero si lo hizo)., El IDE no sabría lo suficiente para que el tipo de retorno que no sea nada var (o tal vez Objeto)

No todo el mundo utiliza el IDE de esta manera en TDD, pero me resulta muy útil. Cuanta más información que puedo dar el IDE en mi prueba, menos escribir tengo que hacer para que el paso de la prueba.