Visual Studio 2010 y Test Driven Development

Question

Estoy dando mis primeros pasos en Test Driven Development con Visual Studio. Tengo algunas preguntas sobre cómo implementar clases genéricas con VS 2010.

Primero, supongamos que deseo implementar mi propia versión de una lista de arreglos. que empezar por crear la siguiente prueba (estoy usando en este caso MSTest):

[TestMethod] 
public void Add_10_Items_Remove_10_Items_Check_Size_Is_Zero() { 
    var myArrayList = new MyArrayList<int>(); 

    for (int i = 0; i < 10; ++i) { 
     myArrayList.Add(i); 
    } 

    for (int i = 0; i < 10; ++i) { 
     myArrayList.RemoveAt(0); //should this mean RemoveAt(int) or RemoveAt(T)? 
           //VS doesn't know. Any work arounds? 
    } 

    int expected = 0; 
    int actual = myArrayList.Size; 
    Assert.AreEqual(expected, actual); 
} 

estoy usando VS 2010 capacidad de golpear

ctrl +.

y lo implementan clases/métodos sobre la marcha.

1. He estado teniendo algunos problemas al implementar clases genéricas. Por ejemplo, cuando defino un método .Add(10), VS no sabe si pretendo un método genérico (ya que la clase es genérica) o un método Add(int number). ¿Hay alguna forma de diferenciar esto?
2. Lo mismo puede ocurrir con los tipos de devolución. Supongamos que estoy implementando una pila MyStack y quiero probar si después de presionar y elemento y abrirlo, la pila todavía está vacía. Todos sabemos que pop debería devolver algo, pero por lo general, el código de esta prueba no debería importarle. Visual Studio pensaría entonces que pop es un método nulo, que de hecho no es lo que uno querría. Como lidiar con esto? Para cada método, ¿debo comenzar haciendo pruebas que sean "muy específicas", como es obvio, el método debería devolver algo para que no tenga este tipo de ambigüedad? Incluso si no usa el resultado, ¿debería tener algo como int popValue = myStack.Pop()?
3. ¿Cómo debo hacer las pruebas a las clases genéricas? ¿Solo prueba con un tipo genérico de tipo? He estado usando int s, ya que son fáciles de usar, pero ¿debo probar también con diferentes tipos de objetos? ¿Cómo usualmente te acercas a esto?
4. Veo que hay una herramienta popular llamada TestDriven para .NET. Con el lanzamiento de VS 2010, ¿sigue siendo útil, o muchas de sus características ahora son parte de VS 2010, dejándolo inútil?
5. Cada vez que defino una nueva propiedad en mi código de prueba, y le pido a VS que me genere ese trozo de método, genera un getter y un setter. Si tengo algo como int val = MyClass.MyProperty me gustaría entender que (al menos todavía) solo quiero definir un getter.

Gracias

Answer 1

Veo que hay una herramienta popular llamado TestDriven para .NET. Con el lanzamiento de VS 2010, ¿sigue siendo útil, o muchas de sus características ahora son parte de VS 2010, dejándolo inútil?

Todavía es útil en caso de que utilice uno de una serie de diferentes marcos de pruebas unitarias (nunit, mbunit, xunit, csunit, etc).

También hay otras herramientas (como Visual Nunit) que proporcionan integración de estudio visual para ejecutar pruebas unitarias.

Answer 2

Para su muestra de código, ¿por qué tendría un método RemoveAt(T obj)?

Puede hacer RemoveAt(int index) y Remove(T obj) en su lugar.Eche un vistazo a las API de Microsoft (por ejemplo, for List<T>) que ven cómo configuran los métodos Eliminar para una colección genérica.

Y ahora para sus puntos:

1: ¿Qué Add(int number) hacer? Si entiendo tus intenciones correctamente, Add(10) solo puede interpretarse como "Agregar valor 10 al final de mi colección". Si desea agregar un valor en un índice en particular, puede (y probablemente debería) nombrar ese método Insertar: Insert(int index, T value).

2: Seguro, Visual Studio interpretará el método vacío al principio, pero se puede editar a ser algo así como

public class MyStack<T> 
{ 
    public T Pop() 
    { 
    } 
} 

El talones construida pulsando Ctrl+. son una conveniencia, pero no Evangelio. NO TIENE que asignar siempre un valor de retorno a una variable. Si no lo necesita en una prueba, no lo haga. Si desea que VS recoja un tipo de devolución que no sea vacío, puede escribir una prueba de unidad diferente (por ejemplo, Pop() devuelve el último valor enviado).

3: Probaría con los tipos que veo con mayor frecuencia en mi código. Si está escribiendo una API pública, pruebe con tantos tipos como sea posible. Si está usando NUnit, investigue usando el atributo [TestCase] para evitar escribir algún código duplicado.

4: Todavía uso TestDriven, pero no he intentado sin él, así que no puedo hacer una comparación útil.

5: Simplemente elimine el colocador si no lo necesita. Algunos frameworks de complementos como ReSharper son compatibles con la generación de código más avanzada, incluidas las propiedades de solo lectura.