Un día en la vida de un desarrollador de ALM: Escribir código nuevo para un caso de usuario

¿Es un usuario nuevo de Visual Studio Application Lifecycle Management (ALM) y Team Foundation Server (TFS)?¿Se está preguntando cómo usted y su equipo pueden obtener el máximo beneficio de la versión más reciente de estas herramientas para compilar la aplicación?

Entonces, tómese unos minutos para seguir paso a paso este tutorial de dos capitulos y siga durante un día las vidas de Peter y de Julia, dos desarrolladores de Fabrikam Fiber, una compañia que provee televisión por cable y otros servicios afines.Verá ejemplos de cómo utilizar Visual Studio y TFS para proteger y actualizar código, suspender el trabajo cuando le interrumpen, solicitar una revisión del código, proteger los cambios, y realizar otras tareas.

La historia hasta ahora

El equipo recientemente comenzó la adopción de Visual Studio y Team Foundation Server para la administración (ALM) del ciclo de vida de la aplicación.Configuraron los equipos del cliente y del servidor, crearon un trabajo pendiente, planearon una iteración y completaron otros planes necesarios para iniciar el desarrollando de su aplicación.

Información general de este capítulo

Peter revisa brevemente el trabajo pendiente y selecciona la tarea en la que trabajará el dia de hoy.Escribe las pruebas unitarias para el código que planea desarrollar.Normalmente, ejecuta las pruebas varias veces en una hora, escribiendo paulatinamente pruebas con todo detalle y,a continuación, el código que las completa.A menudo comenta la interfaz de su código con los colegas que utilizarán el método que está escribiendo.

[!NOTA]

Las caracteristicas de Mi Trabajo y Cobertura de Código comentadas en este tema sólo están disponibles en Visual Studio Premium y Visual Studio Ultimate.

En este tema

• Revise el trabajo personal pendiente y prepare las tareas para iniciar el trabajo

• Crear la primera prueba unitaria

• Crear un código auxiliar para el nuevo código

• Ejecute la primera prueba.

• Acepte el API

• Rojo, verde, refactorizar …

• Cobertura de código

• ¿Cuándo terminamos?

• Proteja los cambios

Revise el trabajo personal pendiente y prepare las tareas para iniciar el trabajo

en Team Explorer, Peter abre la página de mi trabajo .El equipo ha acordado que, durante el sprint actual, Peter trabajara en evaluar el estado de la facturas, un elemento prioritario en el trabajo pendiente del producto.Peter decide comenzar implementando las funciones matemáticas, una tarea secundaria del elemento de trabajo prioritario acumulado.Arrastra esta tarea desde la lista de Elementos de trabajo disponibles hasta la lista de elementos de trabajo y cambios en curso .

Revisar el trabajo personal pendiente y preparar las tareas para comenzar el trabajo

1. En Team Explorer:

   1. Si aún no está conectado al proyecto de equipo en el que desea trabajar, conéctese al mismo.

   2. Elija Inicio y, a continuación, elija Mi Trabajo.

2. En la página Mi trabajo, arrastre la tarea desde la lista de Elementos de trabajo disponibles hasta la sección elementos de trabajo en curso .

   También se puede seleccionar una tarea en la lista Elementos de trabajo disponibles y, a continuación, elija inicio.

Redacte un plan de trabajo incremental

Peter normalmente desarrolla código en una serie de pequeños pasos.Normalmente,cada paso tarda no más de una hora y a veces tan sólo diez minutos.En cada paso, escribe una nueva prueba unitaria y cambia el código que está desarrollando para que pase la nueva prueba, además de las pruebas que ya ha escrito.Unas veces Peter escribe la nueva prueba antes de cambiar el código y, otras veces, cambia el código antes de escribir la prueba.A veces refactoriza.Es decir, sólo mejora el código sin agregar nuevas pruebas.Peter nunca cambia una prueba que pasa, a menos que decida que ésta no representa correctamente un requisito.

Al final de cada pequeño paso ejecuta todas las pruebas unitarias que son relevantes para este área del código.No considera que el paso se ha completado hasta que cada prueba pasa.

Sin embargo, no consignará el código en Team Foundation Server hasta que haya terminado toda la tarea.

Peter diseña un plan preliminar para esta secuencia de pasos pequeños.Sabe que los detalles exactos y el orden de los últimos probablemente cambiarán mientras trabaja.Ésta es su lista inicial de los pasos que hay que seguir para esta tarea concreta:

1. Crea el método del código auxiliar, que es, simplemente, la signatura del método.

2. Presente un caso típico específico.

3. Pruebe una amplia gama.Asegúrese de que el código responde correctamente a una amplia gama de valores.

4. Excepción en negativo.Trate eficazmente los parámetros incorrectos.

5. Cobertura de código.Asegúrese de que las pruebas unitarias realizan al menos el 80% del código.

Algunos de sus compañeros escriben este tipo de plan en comentarios en su código de prueba.Otros simplemente memorizan su plan.Peter cree que es muy útil escribir su lista de pasos en el campo de descripción del elemento de tarea de trabajo.Si tuviera que que cambiar y hacer temporalmente una tarea más urgente, sabría dónde encontrar la lista cuando pueda volver a ella.

Crea la primera prueba unitaria

Peter comienza creando una prueba unitaria.Comienza con la prueba unitaria porque quiere escribir un ejemplo de código que utilice su nueva clase.

Se trata de la primera prueba unitaria para la biblioteca de clases que está probando, por lo que crea un nuevo proyecto de prueba unitaria.Abre el cuadro de diálogo Proyecto nuevo y elige Visual C#, pruebay, a continuación, Proyecto de prueba unitaria.

El proyecto de prueba unitaria proporciona un archivo C# en el que puede escribir su ejemplo.En este momento, sólo quiere mostrar cómo se invocará uno de sus nuevos métodos:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

Escribe el ejemplo en un método de prueba porque,para cuando haya escrito su código,quiere que el ejemplo funcione .

Crear un proyecto de prueba unitaria y métodos.

Normalmente, se crearía un nuevo proyecto de prueba para cada proyecto que se esté probando.Si ya existe un proyecto de prueba, puede agregar simplemente clases y nuevos métodos de prueba.

Este procedimiento utiliza el marco de pruebas unitarias de Visual Studio, pero también puede utilizar marcos de trabajo de otros proveedores.El Explorador de pruebas funciona igual de bien con otros marcos, siempre que se instale el adaptador adecuado.

• Cree un Proyecto de prueba si éste ya no existe.

  • En el cuadro de dialogo Proyecto nuevo, seleccione un lenguaje, como Visual Basic, Visual C++ o Visual C#.Elija prueba y, a continuación, Proyecto de prueba unitaria.

• Agregue las pruebas a la clase de pruebas que se proporciona.Cada prueba unitaria es un método.

  Cada prueba unitaria debe ir precedida del atributo TestMethod ,y el método de prueba unitaria no debe tener ningún parámetro.Se puede utilizar cualquier nombre que se desee para un método de prueba unitaria:

          [TestMethod]
          public void SignatureTest()
          {...}
  

      <TestMethod()>
      Public Sub SignatureTest()
      ...
      End Sub
  

• Cada método de prueba debe llamar a un método de la clase Assert, para indicar si ha pasado o no.Por lo general, se comprueba que los resultados previstos de una operación y los reales son iguales:

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Los métodos de prueba pueden llamar a otros métodos normales que no tienen el atributo TestMethod.

• Las pruebas se pueden organizar en más de una clase.Cada clase debe ir precedida por el atributo TestClass.

  [TestClass]
  public class UnitTest1
  { ... }
  

  <TestClass()>
  Public Class UnitTest1
  ...
  End Class
  

Para obtener más información sobre cómo escribir pruebas unitarias en C++, consulte Escribir pruebas unitarias para C/C++ con el Framework de pruebas unitarias de Microsoft para C++.

Crear un código auxiliar para el nuevo código

A continuación, Peter crea un proyecto de biblioteca de clases para su nuevo código.Ahora tenemos un proyecto para el código en desarrollo y otro proyecto para las pruebas unitarias.Agrega una referencia de proyecto desde el proyecto de prueba al código en desarrollo.

En el nuevo proyecto, agrega la nueva clase y una versión mínima del método que permitirá, por lo menos, que la prueba compile correctamente.La forma más rápida de hacerlo es generar código auxiliar de clase y método desde la invocación en la prueba.

        public double SquareRoot(double p)
        {
            throw new NotImplementedException();
        }

Para generar las clases y los métodos de las pruebas

En primer lugar, cree el proyecto al que desea agregar la nueva clase, a menos que éste ya exista.

Para generar una clase

1. Coloque el cursor en un ejemplo de la clase que desea generar, por ejemplo, LocalMath.En el menú contextual, elija Generar código, Nuevo tipo.

2. En el cuadro de dialogo Nuevo Tipo, establesca proyecto en la biblioteca de clases del proyecto.En este ejemplo, es Fabrikam.Math.

Para generar un metodo

• Coloque el cursor en una llamada al método, por ejemplo, SquareRoot.En el menú contextual, elija Generar código, Código auxiliar del método.

Ejecute la primera prueba.

Peter compila y ejecuta la prueba presionando CTRL + R, T.El resultado de la prueba muestra un indicador de error rojo y la prueba aparece en la lista de Pruebas fallidas.

Realiza un simple cambio en el código:

       public double SquareRoot(double p)
        {
            return 0.0;
        }

Vuelve a ejecutar la prueba y ésta pasa:

Para ejecutar pruebas unitarias

• En el menú Prueba , elija Ejecutar, Todas las pruebas.

  -O bien-

• Si el Explorador de pruebas está abierto, elija Ejecutar todas.

  -O bien-

• Coloque el cursor en un archivo de código de prueba y presione CTRL+R, T.

• Si una prueba aparece en Pruebas Fallidas.

  Abra la prueba, por ejemplo, haciendo doble clic en el nombre.

  Se muestra el punto en el que la prueba falló.

Para ver una lista completa de pruebas, elija Mostrar todo.Para volver al resumen, elija la vista página principal.

Para ver los detalles de un resultado de pruebas, seleccione la prueba en el Explorador de pruebas.

Para navegar al código de una prueba: haga doble click en la prueba en el Explorador de la prueba, o elija Abrir prueba en el menú contextual.

Para depurar una prueba: abra el menú contextual para una o varias pruebas y, a continuación, elija Depurar las pruebas seleccionadas.

Para ejecutar pruebas en segundo plano cada vez que se compila la solución, seleccione Ejecutar pruebas después de compilar.las pruebas que no se pasaron previamente se ejecutan primero.

Acepte la interfaz

Peter llama a su colega Julia en Lynch y comparte su pantalla.Ella utilizará su componente.El le muestra su ejemplo inicial.

Julia piensa que el ejemplo está bien, pero comenta, “Muchas funciones pasarían esa prueba”.

Peter responde, "la primera prueba es sólo para asegurarse de que el nombre y los parámetros de la función son correctos.Ahora podemos escribir una prueba que capture el requisito principal de esta función."

Juntos escriben la siguiente prueba:

  
      [TestMethod]
        public void QuickNonZero()
        {
            // Create an instance to test:
            LocalMath math = new LocalMath();

            // Create a test input and expected value:
            var expectedResult = 4.0;
            var inputValue = expectedResult * expectedResult;

            // Run the method:
            var actualResult = math.SquareRoot(inputValue);

            // Validate the result:
            var allowableError = expectedResult/1e6;
            Assert.AreEqual(expectedResult, actualResult, allowableError,
                "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
        }

Sugerencia

Para esta función, Peter utiliza el desarrollo de pruebas en primer lugar, en el que primero escribe la prueba unitaria para una característica y luego escribe el código que supera la prueba.En otros casos, considera que esta práctica no es realista, así que escribe las pruebas después de escribir el código.Pero considera muy importante escribir pruebas unitarias -ya sea antes o después de código- porque estas mantienen el código estable.

Rojo, verde, refactorizar…

Peter sigue un ciclo en el que repetidamente escribe una prueba y confirma que falla, escribe código para lograr que las pruebas pasen y luego considera refactorizar -es decir, mejorar el código sin cambiar las pruebas.

Red

Peter presiona CTRL + R, T para ejecutar la nueva prueba que creó con Julia.Después de escribir cualquier prueba, Peter siempre la ejecuta para asegurarse de que falla antes de escribir el código que la hace pasar.Esta es una práctica que aprendió después de que olvidara colocar las aserciones en algunas pruebas que había escrito.Ver el resultado de error le da la seguridad de que cuando haga pasar la prueba, el resultado de la misma indicará correctamente que se ha cumplido un requisito.

Otra práctica útil es establecer Ejecutar pruebas después de compilar.Esta opción ejecuta las pruebas en segundo plano cada vez que se compila la solución, de forma que haya un informe continuo del estado de prueba del código.Peter sospechaba al principio que pudiera hacer que Visual Studio respondiera lentamente, pero observó que esto raramente ocurre.

Verde

Peter hace un primer intento de escribir el código del método que está desarrollando:

    public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate;
                estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }
        

Peter ejecuta las pruebas de nuevo y todas las pruebas pasan:

Refactorizar

Ahora que el código realiza su función principal, Peter examina el código para encontrar los modos que le hagan funcionar mejor o para facilitar su cambio en el futuro.Se da cuenta de que puede reducir el número de cálculos realizados en el bucle:

public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate; 
                estimate = (estimate + x / estimate) / 2;
                //was: estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

Comprueba que aún pasan las pruebas:

Sugerencia

Cada cambio que se realiza mientras se desarrolla el código debe ser una refactorización o una extensión: Refactorizar significa que no se cambian las pruebas porque no se va a agregar ninguna funcionalidad nueva. Extensión significa agregar pruebas y realizar los cambios de código que son necesarios para pasar las pruebas nuevas y las ya existentes. Si está actualizando el código existente en los requisitos que han cambiado, eliminará también las antiguas pruebas que ya no representan los requisitos actuales. Evite cambiar las pruebas que ya han pasado.En su lugar, agregue nuevas pruebas.Sólo escriba pruebas que representen un requisito real. Ejecute las pruebas después de cada cambio.

… y repita

Peter continúa su serie de pasos de extensión y de refactorización, utilizando su lista de pasos pequeños como guía básica.No siempre realiza un paso de refactorización después de cada extensión y, a veces, realiza más de un paso de refactorización consecutivo.Pero siempre ejecuta las pruebas unitarias después de cada cambio en el código.

A veces agrega una prueba que no requiere cambios en el código, pero que aumenta su confianza de que su código funciona correctamente.Por ejemplo, quiere asegurarse de que la función opera a través de una amplia gama de entradas.Escribe más pruebas, como ésta:

        [TestMethod]
        public void SqRtValueRange()
        {
            LocalMath math = new LocalMath();
            for (double expectedResult = 1e-8;
                expectedResult < 1e+8;
                expectedResult = expectedResult * 3.2)
            {
                VerifyOneRootValue(math, expectedResult);
            }
        }
        private void VerifyOneRootValue(LocalMath math, double expectedResult)
        {
            double input = expectedResult * expectedResult;
            double actualResult = math.SquareRoot(input);
            Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
        }

Esta prueba pasa la primera vez que ejecuta:

Sólo para asegurarse de que este resultado no es un error, introduce temporalmente un pequeño error en su prueba para hacerla fallar.Después de ver el error, corrige, otra vez.

Sugerencia
Haga siempre que una prueba falle antes de hacerla pasar.

Excepciones

Peter pasa ahora a escribir pruebas para entradas excepcionales:

[TestMethod]
        public void RootTestNegativeInput()
        {
            LocalMath math = new LocalMath();
            try
            {
                math.SquareRoot(-10.0);
            }
            catch (ArgumentOutOfRangeException)
            {
                return;
            }
            catch
            {
                Assert.Fail("Wrong exception on negative input");
                return;
            }
            Assert.Fail("No exception on negative input");
        }

Esta prueba coloca el código en un bucle.Tiene que usar el botón de Cancelar en el Explorador de la prueba.Esto finaliza el código dentro de 10 segundos.

Peter quiere asegurarse de que un bucle sin fin no se puede producir en el servidor de compilación.Aunque el servidor impone un tiempo de espera a una ejecución completa, es un tiempo de espera muy largo y causaría retrasos significativos.Por lo tanto, agrega un tiempo de espera explícito para esta prueba:

        [TestMethod, Timeout(1000)]
        public void RootTestNegativeInput()
        {...

El tiempo de espera explícito hace que la prueba falle.

Peter, a continuación, actualiza el código para tratar este caso excepcional:

       public double SquareRoot(double x)
        {
            if (x <= 0.0) 
            {
                throw new ArgumentOutOfRangeException();
            }

Regresión

La nueva prueba pasa, pero hay una regresión.Una prueba que solía pasar ahora falla:

Peter encuentra y corrige el error:

      public double SquareRoot(double x)
        {
            if (x < 0.0)  // not <=
            {
                throw new ArgumentOutOfRangeException();
            }

Una vez solucionado, todas las pruebas pasan:

Sugerencia
Asegúrese de que cada prueba pasa después de cada cambio realizado en el código.

Cobertura de código

A intervalos durante su trabajo, y, por último, antes de entregar el código, Peter obtiene un Informe de cobertura de código.Este muestra la cantidad de código ejecutado en las pruebas.

El equipo de Pedro tiene como objetivo una cobertura de al menos el 80%.Relajan este requisito para el código generado, porque puede ser difícil lograr una gran cobertura para este tipo de código.

Una buena cobertura no es garantía de que toda la funcionalidad del componente haya sido probada, ni tampoco garantiza que el código funcione para cada rango de valores de entrada.Sin embargo, hay una correlación bastante estrecha entre la cobertura de las líneas de código y la cobertura del espacio de comportamiento de un componente.Por lo tanto, una buena cobertura refuerza la confianza del equipo que está probando la mayoría de los comportamientos que tenía que probar

Para obtener un informe de cobertura de código, en el menú Pruebas, elija Ejecutar, Analizar cobertura de código para todas las pruebas.A continuación, ejecute de nuevo todas las pruebas.

Peter obtiene un 86% de cobertura total.Cuando Peter expande la totalidad en el informe, eśte muestra que el código que el está desarrollando tiene cobertura del 100%.Esto es muy satisfactorio, porque la calificación importante es para el código que se está probando.Las secciones no cubiertas están realmente en las pruebas mismas.Alternando el botón Mostrar colores en cobertura de código, Peter puede ver qué partes del código de prueba no se han utilizado.Sin embargo, decide que estas secciones no son importantes para la cobertura porque están en el código de prueba y sólo se utilizan si se detecta un error.

Para comprobar que una prueba concreta llega a ciertas bifurcaciones de código específicas, se puede establecer Mostrar colores en cobertura de código y trabajar con una sola prueba utilizando el comando Ejecutar en el menú contextual.

¿Cuándo terminamos?

Peter continúa actualizando el código en pequeños pasos hasta que esté convencido que:

• Todas las pruebas unitarias disponibles pasan.

  En un proyecto con un gran conjunto de pruebas unitarias, puede ser poco práctico para un desarrollador esperar a que todas las pruebas se ejecuten.Como alternativa, el proyecto opera un servicio de verificación protegido, en el que todas las pruebas automáticas que se ejecutan para cada conjunto de cambios aplazados y guardados antes de que se funda con el árbol de origen.La protección se rechaza si se produce un error en la ejecución.Este hecho permite al desarrollador ejecutar un conjunto mínimo de pruebas unitarias en su propio equipo y, a continuación, continuar con el trabajo, sin correr el riesgo de romper la compilación.Para obtener más información, vea Definir un proceso de compilación de protección controlada para validar cambios.

• La cobertura de código cumple con los estándares del equipo.El 75% es un requisito normal del proyecto .

• Sus pruebas unitarias simulan todos los aspectos del comportamiento que se requieren, incluyendo entradas típicas y excepcionales.

• Su código es facil de entender y de extender.

Cuando se cumplan todos estos criterios, Peter estará preparado para proteger su código en el control de código fuente.

Principios de desarrollo de código con pruebas unitarias

Cuando desarolla código, Peter aplica los siguientes principios:

• Desarrollar las pruebas unitarias junto con el código y ejecutarlas con frecuencia durante el desarrollo.Las pruebas unitarias representan la especificación del componente.

• No cambie las pruebas unitarias, a menos que se hayan cambiado los requisitos o que las pruebas salieran mal.Agregue nuevas pruebas paulatinamente a medida que extienda la la funcionalidad del código.

• Intente que al menos el 75% de su código esté incluido en las pruebas.Examine los resultados de cobertura de código a intervalos, y antes de comprobar en el código fuente.

• Guarde las pruebas unitarias junto con el código, para que sean ejecutadas por las compilaciones regulares o continuas del servidor.

• Si es viable, para cada parte de funcionalidad, escriba la prueba unitaria en primer lugar.Haga esto antes de desarrollar el código que lo cumple.

Proteja los cambios

Antes de proteger sus cambios, Peter vuelve a utiliza Lync para compartir su pantalla con su colega Julia para que ésta informal e interactivamente pueda revisar con él lo que ha creado.Las pruebas siguen siendo el centro de su discusión porque Julia está principalmente interesada en lo que el código hace, no en cómo funciona.Julia está de acuerdo en que lo que Peter ha escrito satisface sus necesidades.

Peter comprueba en todos los cambios que ha hecho, incluyendo tanto las pruebas como el código y los asocia a la tarea ha completado.El proceso de protección pone en cola el sistema automatizado de compilación del equipo con objeto de validar los cambios mediante el proceso de compilación de integración continua del equipo.Este proceso de compilación ayuda al equipo a minimizar los errores en el código base al compilar y probar, en un entorno limpio separado de los equipos de desarrollo, cada cambio que el equipo hace.

A Peter le notifican cuando se ha completado la compilación.En la ventana de resultados de la compilación , observa que la compilación tuvo éxito y que todas las pruebas pasaron.

Para guardar los cambios

1. En la barra de menús, seleccione Vista, Team Explorer.

2. En Explorador de equipo, elija Home , my wor Inicio y, después, elija Mi Trabajo.

3. En la página Mis trabajos, elija Guardar.

4. Revise el contenido de la página Cambios pendientes para asegurarse de que:

   • Se enumeran todos los cambios pertinentes en Cambios incluidos

   • Todos los elementos de trabajo relevantes se enumeran en Elementos de trabajo relacionados.

5. Especifique un Comentario para ayudar a su equipo a comprender el propósito de estos cambios cuando examinen el historial del control de versiones en los archivos y carpetas cambiados.

6. Elija Comprobar.

Para integrar continuamente el código

Para obtener más información sobre cómo definir un proceso de compilación de integración continua, consulte Definir un proceso de compilación para compatibilidad con integración continua.Tras haber configurado este proceso de compilación, puede elegir que le notifiquen los resultados de las compilaciones del equipo.

Para obtener más información, vea Ejecutar, supervisar y administrar compilaciones.

Siguiente (suspender el trabajo, corregir un error y llevar a cabo una revisión de código)