Poucas pessoas sabem, mas o Visual Studio tem um SDK (Software Development Kit) próprio. Com ele, é possível estender os recursos do Visual Studio (e também do TFS), com a criação de inúmeros componentes, tais como:

• Add-ins e plug-ins para o IDE;
• Políticas de check-in;
• Linguagens de programação (isso mesmo! você pode criar sua própria linguagem de programação e hospedá-la no Visual Studio!);
• Interação com work items;
• E muito mais!

O SDK oferece um navegador muito bacana, no qual é possível encontrar inúmeros exemplos de como utilizar os componentes e bibliotecas oferecidos:

Além de permitir a criação de extensões para o IDE do Visual Studio e para o TFS, o VS SDK é usado para criar as soluções customizadas para o Visual Studio Shell.

Para saber mais sobre o SDK (e a extensibilidade da plataforma Visual Studio), consulte:

• VSX Team Blog
• Visual Studio Extensibility Developer Center
• Visual Studio SDK

Brian Harry acabou de anunciar: o recém-lançado Dynamics AX 2009 agora oferece integração com o controle de versão do TFS!

Less than a month ago, Dynamics AX 2009 was released.  This new version enables Dynamics developers to store their source code and have an integrated experience for checkout, check in, get and history - the basic version control operations in TFS.  I'm excited about this because I get the question fairly often and people are always surprised when I tell them we don't have a solution.  Now I don't have to disappoint any longer.

Para saber como configurar o AX para armazenar o código-fonte no TFS, veja a documentação disponível em http://www.microsoft.com/downloads/details.aspx?FamilyId=EFC24EDC-522E-40AA-8F36-6367ED7AB92D&displaylang=en.

Apesar de o VSTS 2008 já ter sido lançado há um tempo razoável - novembro do ano passado - ainda há muita gente que não sabe o que mudou desde a versão 2005. Por isso, resolvi fazer um resumo das alterações numa série de posts. Irei publicar os links aos poucos, conforme criar os posts.

Veja abaixo os links com os posts resumindo as mudanças da nova versão do Team System. IMPORTANTE: Aqui você encontra apenas os recursos específicos do Team System (TFS e Team Editions).

• O que há de novo no Team Foundation Server 2008?
• O que há de novo no Team Build 2008?
• O que há de novo no VSTS Architecture Edition 2008?
• O que há de novo no VSTS Development Edition 2008?
• O que há de novo no VSTS Test Edition 2008?
• O que há de novo no VSTS Database Edition 2008?

Para saber mais sobre as mudanças no Visual Studio e no .NET Framework:

• O que há de novo no Visual Studio 2008?
  http://msdn2.microsoft.com/en-us/library/bb386063.aspx
• O que há de novo no .NET Framework 3.5?
  http://msdn.microsoft.com/en-us/library/bb332048.aspx

O Team Foundation ainda é alvo de muito preconceito da comunidade de desenvolvedores. Só porque o nome do produto é “Microsoft Visual Studio Team System Team Foundation Server” (pequeno, né?) a maioria presume que TFS = .NET, já que assumem que Visual Studio = .NET. Bem, nada mais equivocado.

O ponto importante a se lembrar aqui é: O Visual Studio Team System é uma plataforma de ALM. ALM, ou Application Lifecycle Management, refere-se às práticas envolvidas na gestão do ciclo de vida de uma aplicação – desde a sua concepção, especificação e planejamento até a efetiva implantação no ambiente de produção. Repare que em nenhum lugar estava escrito “.NET Application Lifecycle Management”. Assim, ainda que obviamente a plataforma tenha recursos específicos para .NET (capazes de aumentar a qualidade e eficiência do trabalho da equipe de desenvolvimento), eu realmente acredito que nossa plataforma brilha nos cenários em que há vários ambientes (e linguagens) de desenvolvimento envolvidos.

Na sua empresa há um ambiente heterogêneo de programação? Há grandes chances que a resposta seja “sim”. Na maioria dos clientes que tenho visitado o mais comum é termos algo como “VB6 + .NET”, ou “Java + .NET”, ou “Delphi + VB + Java”, ou qualquer outra combinação que você imaginar. Como se não bastasse o fato de ter que lidar com múltiplas linguagens de programação, esses clientes normalmente acabam lidando com várias ferramentas usadas ao mesmo tempo no apoio à ALM: VSS, CVS, Subversion, Jira, Trac, Project Server, Primavera etc…

Quem já não viu esse cenário? “Projetos Java no Subversion, projetos VB no SourceSafe”. Como conseguir gerenciar isso de forma efetiva?

A resposta é clara: Use o Team Foundation Server para todos os projetos, independentemente da linguagem!

Eclipse

Veja o caso do Eclipse, um dos IDEs mais utilizados no desenvolvimento de aplicações Java (usando o plugin Teamprise). Com ele, você tem acesso total aos recursos do TFS – controle de versão, rastreamento de itens de trabalho, relatórios e documentos:

MSSCCI Provider

Há vários IDEs que ainda não oferecem suporte nativo ao TFS. Porém, se eles tiverem suporte ao Visual SourceSafe, há grandes chances de usar o TFS no lugar do VSS. Basta que eles se conectem ao VSS através de uma API chamada MSSCCI (Microsoft Source Code Control Interface). Com o Visual Studio Team Foundation Server MSSCCI Provider é possível “enganar” seu IDE, de modo que ele “fale” com o TFS pensando que é o SourceSafe. Alguns dos IDEs que utilizam essa API e que foram testados pela Microsoft para usar o MSSCCI Provider são:

• Visual Studio .NET 2003
• Visual C++ 6 SP6
• Visual Visual Basic 6 SP6
• Visual FoxPro 9 SP1
• Microsoft Access 2003 SP2
• SQL Server Management Studio
• Sparx Systems Enterprise Architect 6.1
• Sybase PowerBuilder 10.5
• Toad for SQL Server 2.0

Para saber mais, há um artigo (já um tanto antigo, mas ainda válido) sobre o assunto em http://www.microsoft.com/brasil/msdn/tecnologias/vs2005/tfs.mspx.

Você já desenvolveu alguma ferramenta para estender a funcionalidade do Team System? Conhece alguém que criou um programinha tão legal que mudou seu jeito de usar a solução de ALM da Microsoft? Que tal participar de um concurso para eleger o gadget mais legal para o Team System?

Mike Azocar, MVP de Team System, propôs o concurso Coolest Team System Gadget Contest. Do blog do Mike:

Have you created a useful gadget for Team System? Do you have one in mind? I am looking for the coolest community built tool for VSTS. It can be something for TFS, for Visual Studio, or something that is stand alone. The winner will receive a one year subscription to MSDN with Team Suite and a one year subscription to Infragistics NetAdvantage controls!

To enter, submit a screen cast (up to 3 minutes long) which tells everyone why your gadget is the coolest and the source code. All submissions will be released to the public as free source to use and enjoy (with you getting all the credit of course). Videos will also be made available to the public to help make you famous! This should be something new (i.e. not on Codeplex or previously released) and not something repackaged.

Inscreva-se até o dia 31/agosto. O vencedor será anunciado no dia 15/setembro. Inscreva-se! Vote no seu preferido!

Mais uma da série "dúvidas comuns sobre o Team System": Muitos clientes nos perguntam se é preciso instalar alguma versão do Visual Studio Team System no servidor de build (mais precisamente no agente de build - essa é a nomenclatura correta).

A resposta curta é: Provavelmente. A resposta completa é:

Se você pretende usar em seus builds algum dos recursos a seguir:

• Testes em geral (unitários, web, carga etc.);
• Análise Estática de Código (Code Analysis);
• Testes Unitários de Banco de Dados;
• Compilação e Implantação de Projetos de Banco de Dados.

Então você precisará instalar a versão adequada do Visual Studio no agente de build. Isso se deve ao fato de que os recursos listados acima são exclusivo do IDE, sendo "aproveitados" pelo agente no ato da execução do build. As DLLs que executam cada uma das funções acima não podem ser instaladas individualmente; para isso você deve instalar o Visual Studio, de acordo com a tabela abaixo:

Para simplificar o processo de seleção listado na tabela acima, muitos de nossos clientes preferem instalar o Team Suite nos agentes de build.

Licenciamento

Este é um ponto muito importante: Na maioria dos casos, você NÃO PRECISA COMPRAR uma licença adicional para seus agentes de build. O licenciamento segue a seguinte lógica:

"A pessoa que criar o script de build pode instalar no agente de build a mesma licença que ela tem para uso em seu próprio computador"

Em outras palavras: Se eu tiver um Visual Studio Team System Development Edition (que eu uso no dia-a-dia para desenvolvimento dos meus sistemas) e for o responsável por criar o script de build, isso me dá o direito a:

1. Adicionar o recurso de Análise de Código (que faz parte do Development Edition) ao meu script de build;
2. Instalar o Visual Studio Team System Development Edition (que é a licença que eu tenho em meu próprio computador) no servidor de build, sem custo adicional.

Por isso, se você quiser usar num mesmo script de build os recursos de análise de código (Development Edition), testes (Test Edition) e banco de dados (Database Edition), a pessoa que cria o script de build deve ter o Team Suite.

Antes de discutir cobertura de código, uma rápida recapitulação:

• Cobertura de código: Uma métrica que indica a efetividade dos testes feitos em uma aplicação. Expressa em termos de porcentagem do código-fonte da aplicação, mostra extaamente o quanto da aplicação foi testada durante uma dada bateria de testes;
• Testes Unitários: Pequenas rotinas (tipicamente escritas na mesma linguagem de programação do sistema que será testado) que descrevem regras de negócios e outros comportamentos conhecidos e esperados do sistema. Os testes unitários invocam rotinas e outras pequenas porções de código do sistema-alvo, suprindo parâmetros com valores pré-definidos e analisando o comportamento resultante, que deve estar de acordo com a regra de negócio ou comportamento esperado em questão.

Para que os testes unitários sejam efetivos, eles devem cobrir o maior número possível de "caminhos" no código da aplicação. A cobertura de código visa a responder justamente o quanto desses caminhos foi realmente testado. Veja um exemplo (totalmente fictício, hein?!) que ilustra tudo isso:

   1:  public class Empregado
   2:  {
   3:      public static double CalcularSalario(double salarioBruto, bool temPlanoSaude, bool temValeRefeicao)
   4:      {
   5:          var salarioLiquido = salarioBruto;
   6:   
   7:          // Cálculo do imposto de renda
   8:   
   9:          if (salarioBruto > 1000 && salarioLiquido <= 2000)
  10:          {
  11:              salarioLiquido -= (salarioBruto * .05);
  12:          }
  13:          else if (salarioBruto > 2000 && salarioBruto <= 3000)
  14:          {
  15:              salarioLiquido -= (salarioBruto * .15);
  16:          }
  17:          else if (salarioBruto > 3000)
  18:          {
  19:              salarioLiquido -= (salarioBruto * .25);
  20:          }
  21:   
  22:          // Cálculo do plano de saúde
  23:   
  24:          if (temPlanoSaude)
  25:          {
  26:              salarioLiquido -= (salarioBruto * .10);
  27:          }
  28:   
  29:          // Cálculo do vale-refeição
  30:   
  31:          if (temValeRefeicao)
  32:          {
  33:              salarioLiquido -= (salarioBruto * .05);
  34:          }
  35:   
  36:          return salarioLiquido;
  37:      }
  38:  }

public void CalcularSalarioTest()
{
    // "Valores conhecidos". São arbitrários; posso usar qualquer valor

    double salarioBruto = 1500; 
    bool temPlanoSaude = false; 
    bool temValeRefeicao = true; 

    // "Valor esperado". Deve estar de acordo com a regra de negócio e com
    // os valores dados acima

    double expected = 1350; 

    // "Valor real". É o valor que será retornado pela minha rotina de cálculo;
    // se tudo der certo, deve ser igual ao "valor esperado"

    double actual;

    // Executa a rotina passando os valores acima como parâmetros

    actual = Empregado.CalcularSalario(salarioBruto, temPlanoSaude, temValeRefeicao);

    // Confere se os resultados ("valor esperado", "valor real") são iguais; se forem,
    // o teste é considerado bem-sucedido

    Assert.AreEqual(expected, actual);
} 

Compare a regra de negócio, o código-fonte da aplicação e o teste unitário:

• A rotina de cálculo está atendendo a todas as premissas da regra de negócio? No exemplo acima, sim.
• O teste unitário está testando todas as variações possíveis da rotina de cálculo? No exemplo acima, não está:
  • Não foram feitos testes para todas as faixas de salários (para garantir que o IRPF está sendo calculado corretamente);
  • Não foram testadas outras variações para "plano de saúde" e "vale-refeição".

É justamente nesse momento que entra a cobertura de código. Ela nos ajuda a identificar quais pontos da rotina não foram testados:

Viu? A cobertura de código é quase indispensável quando estamos trabalhando com testes unitários. Ela nos dá a medida da eficácia do teste que escrevemos e acabamos de executar. Daí vem uma dúvida bastante comum quando discutimos cobertura de código e testes unitários no Team System. Tipicamente esses dois recursos são mostrados em conjunto - e por isso há quem acredite que são parte da mesma funcionalidade, e que portanto cobertura de código significa "porcentagem do código testado pelos testes unitários", quando na verdade significa "porcentagem do código testado"!

Cobertura de Código e outros testes

Veja como a cobertura de código se comporta em conjunto com alguns dos outros testes disponíveis no Team System. Para isso, crie uma solução com dois projetos: uma Web Application e um Test Project. Não se esqueça de ativar a cobertura de código para seu projeto Web Application (Test | Edit Test Run Configurations | Local Test Run):

Testes Manuais

Faça uma experiência: adicione um teste manual e execute-o. Enquanto ele estiver em execução, abra o seu web site (que deve ter sido carregado automaticamente pelo Visual Studio). Navegue à vontade pelas páginas de teste que você deve ter criado (espero que sim!). Depois, no Visual Studio, marque o teste manual como concluído:

Ao clicar numa das opções acima (e em seguida em Apply) você terá concluído o teste. Inspecione agora a janela de resultado da cobertura de código (Test | Windows | Code Coverage Results). Veja como a cobertura de código foi corretamente preenchida de acordo com as páginas que você navegou:

Testes Web e Testes de Carga

Testes Web (Web Test) e Testes de Carga (Load Test) também alimentam a cobertura de código. Faça seus testes e confira!

Outros tipos de testes

Veja como alguns dos outros tipos de teste disponíveis no Team System se comportam quanto à cobertura de código:

• Testes Unitários de Banco de Dados: Esses testes nada mais são que o teste unitário convencional com algumas facilidades para a execução de T-SQL. Na verdade, por baixo dos panos eles são .NET puro. Assim, se por acaso invocarem trechos da sua aplicação então a cobertura de código refletirá tal fato;
• Testes Ordenados: Como estes são nada mais que agrupadores de outros testes, estarão sujeitos às regras aplicáveis a cada um dos "sub-testes" que os compõem;
• Testes Genéricos: Esses testes existem para que possamos testar componentes não- .NET ou que sejam externos à nossa aplicação. Assim, não faz sentido esperar que esses testes "sensibilizem" a cobertura de código.

Conclusão

A cobertura de código é um recurso muito importante da Test Edition do Visual Studio Team System, e está disponível para a maioria dos tipos de testes - não só para testes unitários. Use e abuse da cobertura de código!