Dia na vida de um desenvolvedor de ALM: escrever um novo código para uma história de usuário

Você são um novo usuário (ALM) de gerenciamento do ciclo de vida do aplicativo do Visual Studio e o Team Foundation Server (TFS)?Você está querendo você saber como e sua equipe podem obter o máximo benefício da versão mais recente de essas ferramentas para criar seu app?

Então utiliza a alguns minutos direto a passo a passo de exame este tutorial de dois capítulo e siga um dia em vidas de Peter e de Julia, dois desenvolvedores na empresa fictícia de Fibra - um de Fabrikam que fornece televisão por cabo e serviços relacionados.Você verá exemplos de como você pode usar o Visual Studio e TFS para fazer check-out e atualizar o código, suspende o trabalho é desfeito, quando você solicita uma revisão de código, fazer check-in de suas alterações, e executa outras tarefas.

Até agora a essa história

O team adotando Visual Studio e o Team Foundation Server para o gerenciamento (ALM) do ciclo de vida do aplicativocomeçou recentemente.Configurar o servidor e as máquinas clientes, criou uma reserva, planejada uma iteração, e concluída outro planejar necessário iniciar a desenvolver seu app.

Visão geral de este capítulo

Peter analise rapidamente sua reserva e seleciona a tarefa que funcionará sobre hoje.Grava testes de unidade para o código que planeja desenvolver.Normalmente, executa os testes várias vezes em uma hora, escrevendo gradualmente teste mais detalhada e escrevendo no código que as torna passar.Discute geralmente a interface do seu código com os colegas que usará o método que está escrevendo.

Observação
Meus recursos de tinta de trabalho e de código que são abordados em este tópico estão disponíveis somente em Visual Studio Premium e em Visual Studio Ultimate.

Neste tópico

• Examinar a reserva pessoais e prepare tarefas iniciar o trabalho

• Crie o teste da primeira unidade

• Crie um stub para o novo código

• Executar o primeiro teste

• Concorde API

• Vermelho, verde, Refactor…

• Cobertura de código

• Quando estiverem feitos?

• Fazer o check-in das alterações

Examinar a reserva pessoais e prepare tarefas iniciar o trabalho

Em Team Explorer, Peter abra a página de Meu Trabalho .O team concordou que, durante a sprint atual, Peter irá trabalhar no status de fatura Evaluate, um item de prioridade máxima de retorno do produto.Peter decidir começar com funções matemáticas de implementar, uma tarefa filho do item de fallback. prioridade maxArrastar essa tarefa da lista de Itens de trabalho disponíveis na lista de Itens & alterações em andamento de trabalho .

Para examinar a reserva pessoais e preparar tarefas iniciar o trabalho

1. Em Team Explorer:

   1. Se você não está mais conectado ao projeto de equipe que você deseja trabalhar em seguida, se conectar ao projeto de equipe.

   2. InícioEscolha , e escolhaMeu Trabalho.

2. Em a página de Meu Trabalho , arraste a tarefa da lista de Itens de trabalho disponíveis à seção de Itens em andamento de trabalho .

   Você também pode selecionar uma tarefa na lista de Itens de trabalho disponíveis e então escolha Iniciar.

Plano de trabalho incremental de esboço

Peter desenvolver geralmente o código em uma série de etapas pequenas.Cada etapa usa normalmente não mais do que uma hora, e pode levar tão vez quanto dez minutos.Em cada etapa, grava um novo testes de unidade e modifica o código que está desenvolvendo de modo que passa o novo teste, além dos testes que já tenha escrito.A as vezes copia o novo teste antes de alterar o código, e às vezes altera o código antes de escrever o teste.A as vezes em ele refactors.Isto é, aumenta apenas o código sem adicionar novos teste.Nunca mudar um teste que passa, a menos que não decidir que representava corretamente um requisito.

Em o final de cada etapa pequena, executa todos os testes de unidade que são relevantes à área de código.Não considera a etapa completo até que cada teste passem.

Em o entanto, não irá o código no Team Foundation Server até terminar a tarefa inteira.

Peter escreve para baixo um plano áspero para essa seqüência de etapas pequenas.Sabe que os detalhes e ordem exata de posteriores se alterarão provavelmente como funciona.Aqui está inicial da lista as etapas para esta tarefa específica:

1. Crie o método que é stub-, apenas a assinatura de teste do método.

2. Como alvo um típico caso específico.

3. Testar o intervalo amplo.Certifique-se que o código responde corretamente a um grande variedade de valores.

4. Exceção em negativo.Normalmente lidar com parâmetros incorretos.

5. Cobertura de código.Certifique-se de que o menos 80% do código está exercitado pelos testes de unidade.

Alguns dos seus colegas gravam esse tipo de fundo nos comentários no código de teste.Outro apenas memorizam seu plano.Peter ser útil gravar sua lista de etapas no campo de descrição de item de trabalho de tarefas.Se tem que alternar temporariamente a uma tarefa com mais urgência, ele sabe onde localizar a lista quando ela pode retornar.

Crie o teste da primeira unidade

Peter inicia criando um teste de unidade.Começa com o teste de unidade porque deseja escrever um código exemplo que usa a nova classe.

Este é o teste da primeira unidade para a biblioteca de classes que está testando, o que cria um novo projeto de teste de unidade.Abre a caixa de diálogo de Novo Projeto e escolhe Visual C#, Testar, e então Projeto de teste de unidade.

O projeto de teste de unidade fornece um arquivo C# em que pode escrever o exemplo.Em esta etapa, apenas quiser ilustrar como um dos novos métodos será chamado:

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);
        }
    }
}

Grava o exemplo em um método de teste, como antes que escrever seu código, desejar que o exemplo funcione.

Para criar um teste de unidade projeto e métodos

Geralmente você deve criar um novo projeto de teste para cada projeto que está sendo testado.Se um projeto de teste já existe, você pode simplesmente adicionar novos métodos e classes de teste.

Este procedimento usa a estrutura de testes de unidade do Visual Studio, mas você também pode usar estruturas de outros provedores.O teste Explorer também funciona bem com outras estruturas, desde que você instala o adaptador apropriado.

• Crie um projeto de teste, se ainda não existir.

  • Em a caixa de diálogo de Novo Projeto , escolha um idioma como Visual Basic, Visual C++ ou Visual C#.Escolha Testar e em seguida Projeto de teste de unidade.

• Adicione seus testes para a classe de teste que é fornecida.Cada testes de unidade é um método.

  Cada testes de unidade deve ser prefixado pelo atributo de TestMethod , e o método de testes de unidade não deve ter nenhum parâmetro.Você pode usar qualquer nome que você deseja um método de testes de unidade:

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

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

• Cada método de teste deve chamar um método da classe de Assert , para indicar se passou ou falhou.Normalmente, verifique que os resultados esperados e reais de uma operação sejam iguais:

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Os métodos de teste podem chamar outros métodos comuns que não têm o atributo de TestMethod .

• Você pode organizar seus testes em mais de uma classe.Cada classe deve ser prefixados pelo atributo de TestClass .

  [TestClass]
  public class UnitTest1
  { ... }
  

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

Para obter mais informações sobre como escrever testes de unidade em C++, consulte Escrever testes de unidade para C/C++ com o Microsoft Unit Testing Framework para C++.

Crie um stub para o novo código

Em seguida, Peter cria um projeto de biblioteca de classes para o novo código.Agora há um projeto para o código em desenvolvimento e um projeto para os testes de unidade.Adiciona uma referência de projeto do projeto de teste para o código em desenvolvimento.

Em o novo projeto, adiciona a nova classe e uma versão mínima do método que permitirá pelo menos que o teste compila com êxito.A maneira mais rápido para fazer isso é gerar um stub da classe e o método de chamada no teste.

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

Para gerar classes e métodos de teste

Primeiro, crie o projeto onde você deseja adicionar a nova classe, a menos que já existir.

Para gerar uma classe

1. Coloque o cursor em um exemplo da classe que você deseja gerar, por exemplo, LocalMath.Em o menu de atalho, escolha Gerar código, novo tipo.

2. Em a caixa de diálogo de novo tipo , defina Projeto ao projeto de biblioteca de classes.Em esse exemplo, é Fabrikam.Math.

Para gerar um método

• Coloque o cursor em uma chamada para o método, por exemplo, SquareRoot.Em o menu de atalho, escolha Gerar código, Stub de método.

Executar o primeiro teste

Peter compila e executa o teste pressionando CTRL+R, T.O resultado de teste mostra um indexador falha vermelho e testar aparece na lista de Testes com falha.

Fizer uma alteração simples para código:

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

Executa um teste novamente e passa:

Para executar testes de unidade

• Em o menu de Testar , escolha Executar, Todos os testes.

  - ou -

• Se o teste Explorer estiver aberto, escolha Executar todas.

  - ou -

• Coloque o cursor em um arquivo de código de teste e em um pressionamento CTRL+R, T.

• Se um teste aparece em Testes com falha:

  Abra o teste, por exemplo, clicando duas vezes no nome.

  o ponto em que o teste falhou é exibido.

Para ver uma lista completa de teste, escolher Mostrar Tudo.Para retornar ao resumo, escolha o modo de INÍCIO .

Para ver os detalhes de um resultado de teste, seleciona o teste no teste Explorer.

Para navegar para o código de um teste, clique duas vezes no teste no teste Explorer, teste aberto ou escolha no menu de atalho.

para depurar um teste, abre o menu de atalho para um ou mais testes, e clique em Testando selecionados depuração.

Alternância Teste de execução após a compilaçãodePara executar um teste no plano de fundo sempre que você criar a solução, .Teste que falhou anteriormente são executados primeiro.

Concorde a interface

Peter chama o Julia colega em Lync, e compartilha a tela.Estará usando o componente.O exemplo a seguir mostra inicial.

Julia acha que o exemplo é OK, mas os comentários, “muitas funções transmitiriam que o teste.”

Peter responde, o primeiro “teste é apenas certificar-se de que o nome e parâmetros da função estão corretos.Agora nós podemos escrever um teste que captura o requisito chave de essa função.”

Junto a seguir gravam o teste:

  
      [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);
        }

Dica

Para essa função, Peter estiver usando o primeiro desenvolvimento de testes, que grava no primeiro testes de unidade para um recurso e em seguida, grava código que satisfaz o teste.Em outros casos, localiza que esta prática não é tão realística, em vez de isso, ele grava os testes após escrever código.Mas é muito importante escrever a unidade teste- se antes ou depois do como manter o código e estável.

Vermelho, verde, Refactor…

Peter segue um ciclo em que grava repetidamente um teste e confirme que falha de código, grava para fazer um teste de clique, e então passar considera que é refactoring-, melhorando o código sem alterar os testes.

Vermelho

Peter pressione CTRL+R, T para executar o novo teste que criou com a Julia.Depois que escrever qualquer teste, ele executa sempre ele para certificar-se que falha antes que escrever código que faz o passado.Essa é uma prática aprendeu que depois que tiver esquecido coloque declarações em qualquer teste tivesse escrito.Consulte o resultado de falha de confiança que quando o fizer, passe o resultado de teste corretamente indica que um requisito foi satisfeito.

Outra prática útil é definir Teste de execução após a compilação.Essa opção executa os testes no plano de fundo cada vez que você criar a solução, para que você tenha um relatório contínuo de status de teste de seu código.Peter estava em primeiro suspeito que pode fazer ao Visual Studio lento para responder, mas localiza que isso acontece contrário.

Verde

Peter grava a primeira tentativa no código do método que está desenvolvendo:

    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 executa o teste novamente e todos os testes passam:

Refatorar

Agora que o código executa sua função principal, Peter examinar o código para encontrar maneiras para torná-lo executa melhor, ou para facilitar alteração no futuro.Realiza que pode reduzir o número de cálculos executados no loop:

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;
        }

Verifica que testa ainda passem:

Dica

Cada alteração que você faz quando você desenvolver código deve ser refatoração ou uma extensão: Refatoração significa que você não altera os testes porque você não estiver adicionando uma nova funcionalidade. A extensão significa adicionar teste e fazer alterações de código que são necessárias para passar teste novos e existentes. Se você estiver atualizando o código existente aos requisitos que foram alterados, você também excluir os testes antigos que não representam os requisitos atual. Evite alterar os testes que já tenham passado.Em vez de isso, adicione novos teste.Escreva somente os testes que representam um requisito real. Executar testes após cada alteração.

… e repetição

Peter continua a extensão e série de etapas de refatoração, usando sua lista de etapas pequenas como um termo de referência.Não sempre executa uma etapa de refatoração após cada extensão, e executa às vezes mais de uma etapa de refatoração sucessivamente.Mas sempre executa os testes de unidade após cada alteração no código.

A as vezes adiciona um teste que não requer nenhuma alteração no código, mas que adiciona à sua confiança que seu código funciona corretamente.Por exemplo, quiser garantir que a função funciona em uma ampla gama de entradas.Grava mais testes, como este:

        [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);
        }

Este teste passa a primeira vez que executa:

Certificar-se de resultado não apenas este é um erro, ele apresenta temporariamente um pequeno erro no seu teste para torná-lo falhar.Após consultado a falha, corrigir-la novamente.

Dica
Faça sempre um teste falhar antes que você faça o passado.

Exceções

Agora Peter move sobre a escrita de teste para entradas excepcionais:

[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");
        }

Este teste coloca o código em um loop.Tem que usar o botão de Cancelar no teste Explorer.Isso finaliza o código dentro de 10 segundos.

Peter deseja verificar se um loop infinito não pode acontecer no servidor de compilação.Embora o servidor impor um tempo limite em uma execução completo, um tempo limite é muito longo, e poderiam causar atraso considerável.Portanto, adiciona um tempo limite explícito a esse teste:

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

o tempo limite explícito faz o teste falhar.

Peter atualiza o código para manipular esses casos excepcionais:

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

Regressão

As novas passa de teste, mas há uma regressão.Um teste que o usa para passar agora falha:

Localiza e correções de Peter o erro:

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

Depois que foi corrigido, todos os testes passam:

Dica
Certifique-se de cada passa de testes após cada alteração que você fizer o código.

Codificar a tinta

Em intervalos durante seu trabalho, e finalmente antes de fazer o check-in no código, Peter obtém um relatório de tinta de código.Isso mostra quanto de código foi exercitado pelos testes.

A equipe de Peter aponta para a tinta pelo menos de 80%.Relaxam esse requisito para o código gerado, porque pode ser difícil obter uma cobertura alta para esse tipo de código.

Boa a tinta não garante que a funcionalidade completa do componente foi testada, e não garante que o código funcionará para cada intervalo de valores de entrada.Entretanto, há uma correlação bastante próximo entre a tinta de linhas de código e a tinta de espaço de comportamento de um componente.Portanto, a tinta reforça confiança boa de equipe que está testando a maior parte do comportamento que deve.

Para obter um relatório de tinta de código, no menu de Testes , escolha Executar, Analisar a tinta de código para todos os testes.Executar em todos os testes novamente.

Peter obtém uma cobertura total de 86%.Quando ele expande o total no relatório, que mostra o código que está desenvolvendo tem uma cobertura de 100%.Isso é muito satisfatório, porque a contagem é importante para o código no teste.As seções descobertas são realmente de testes próprios.Ativando /desativar o botão de Coloração de tinta de código de apresentação , Peter pode ver que partes do código de teste não foram exercitadas.Em o entanto, decidir que essas operações são sem importância para a tinta como estão no código de teste e devem ser usadas somente se um erro for detectado.

Para verificar que um teste o escopo específico em ramificações específicos de código, você pode definir Coloração de tinta de código de apresentação e então executar o único teste de Executar usando o comando no menu de atalho.

Quando estiverem feitos?

Peter continua a atualizar código nas etapas pequenas até que esteja convicto que:

• Qualquer passagem disponível de testes de unidade.

  Em um projeto com um conjunto grande de testes de unidade, pode ser prático para um desenvolvedor esperá-los todos para executar.Em vez de isso, o projeto opera um serviço de check-in com barreira, em que todos os testes automatizados são executadas para cada check-in particular registrados antes de ser mesclado na árvore de origem.O check-in é descartado se a execução falhar.Isso permite que o desenvolvedor executar um conjunto mínimo de testes de unidade no seu computador, e depois continuar com outro trabalho, sem executar o risco de interromper a compilação.Para mais informações, consulte Definir um processo de compilação Gated Check-In para validar as alterações.

• A tinta de código encontra o padrão de equipe.75% é um requisito comum de projeto.

• Seus testes de unidade simulam todos os aspectos do comportamento que é necessária, incluindo entradas típicas e excepcionais.

• Seu código é fácil de entender e estender.

Quando todos esses critérios estão localizados, Peter está pronto para verificar seu código no controle de origem.

Noções básicas de desenvolvimento de código com testes de unidade

Peter utiliza os seguintes princípios quando código se tornando:

• Desenvolva testes de unidade juntamente com o código, e executar com freqüência durante o desenvolvimento.Os testes de unidade representam a especificação do componente.

• Não altere testes de unidade, a menos que os requisitos foram alteradas ou os testes são inexatos.Adicionar novos teste gradualmente como você estender a funcionalidade de código.

• Aponta para pelo menos 75% do seu código seja tratado pelos testes.Veja os resultados de tinta de código em intervalos, e antes de fazer o check-in no código-fonte.

• Fazer check-in seus testes de unidade juntamente com o código, de modo que sejam executados pelas compilações contínuas ou normais do servidor.

• Onde for prático, para cada parte da funcionalidade, escreva o teste de unidade primeiro.Faça isso antes que você desenvolva o código que o conteúdo.

Fazer o check-in das alterações

Antes de fazer o check-in de suas alterações, Peter usa novamente Lync para compartilhar sua tela com seu colega Julia para que ele pode informal e interativamente examinar a ele o que criou.Os testes continuam a ser o foco da discussão porque Julia é primeiro interessada em que o código faz, não funciona como.Julia concorda que Peter escreveu atender às necessidades.

Peter fazer o check-in das alterações que fez, incluindo os testes e o código, e associá-los com a tarefa terminado.O check-in enfileira o sistema de compilação automatizado de equipe de equipe para validar as alterações usando o processo de criação de compilação de CI de equipe.Este processo de compilação ajuda a equipe minimizar erros no codebase criando e testes- em um ambiente limpa separar o desenvolvimento de máquina cada alteração que faz a equipe.

Peter é notificado quando a compilação for concluída.Compilação resulta na janela, consulta que a compilação foi bem-sucedida e todos os testes tiverem passado.

Para fazer o check-in das alterações

1. Em a barra de menu, escolha Modo de Visualização, Team Explorer.

2. Em Team ExplorerInício , escolha, e escolha Meu Trabalho.

3. Em a página de Meu Trabalho , escolha Fazer Check-in.

4. Examinar o conteúdo da página de Alterações pendentes para certificar-se que:

   • Todas as alterações relevantes são listadas em Alterações Incluídas

   • Todos os itens de trabalho relevantes são listados em Itens de Trabalho Relacionados.

5. Especificar Comentário sua equipe para ajudar a entender a finalidade de essas alterações aparecem quando o histórico de controle de versão dos arquivos e pastas alterados.

6. Escolha Fazer Check-in.

Para integrar continuamente o código

Para obter mais informações sobre como definir um processo contínuo de compilação de integração, consulte Definir um processo de compilação para oferecer suporte a integração contínua.Após você ter configurado este processo de compilação, você pode escolher ser notificado sobre os resultados de compilações de equipe.

Para mais informações, consulte Executar, monitorar e gerenciar as compilações.

Next (suspenda o trabalho, corrigir um bug, e unidade uma revisão de código)