Visual Studio Team System vs Open Source – Parte 1

Uma pergunta que tenho ouvido freqüentemente seja em listas de discussões, eventos ou mesmo em clientes é “Por que eu preciso do Team System? ”. Normalmente, após essa pergunta eu ouço também uma justificativa muito comum dizendo que tudo o que o VSTS oferece já está disponível no mundo Open Source e é completamente gratuito.

Bom, para tentar responder a essa pergunta eu preparei uma série de comparações que espero que os ajudem a entender porque o Visual Studio Team System é diferente.

Antes de tudo, quero deixar claro que não sou contra software open source, alias já usei muito Eclipse, JUnit, Ant, Hibernate, CVS além de todas essas variações para a plataforma .NET, mas realmente não dá para comparar essa “Salada de Frameworks/Ferramentas Open Source” com o plataforma de ALM (Application Lifecycle Management) da Microsoft. Vamos lá então:

NUnit vs Visual Studio Test Edition (VSTE)  

Essa eu acho que é a campeã! Já perdi a conta das vezes que ouvi o pessoal dizendo que o NUnit e o VSTE são a mesma coisa. Não, não são! O NUnit é um excelente framework para execução de testes unitários e apenas isso.

Antes de iniciar a comparação, deixe-me fazer algumas perguntas sobre o NUnit:

• Ele Faz Web Test?
• Faz teste de carga?
• Tem cobertura de código integrada?
• Oferece agentes para serem instalados em desktops para coordenarem um verdadeiro teste de carga?
• Tem integração com Work Items?
• Tem integração com Build?
• Ele gerencia testes manuais (Test Case)?
• Possui integração com o Visual Studio?
• Alimenta bancos de dados para eu extrair relatórios com informações sobre os testes?

Então meu amigo, não dá para compará-los. Para compará-los, precisaríamos fazer uma combinação de uma série de outros frameworks, como por exemplo, NUnit + NUnitReport + NCover + NCoverExplorer + NUnitAsp + NAnt + TestDriven.NET e por aí vai.

Imagens 1 e 2: NCoverExplorer e NUnit

Supondo que você teve muita paciência, um pouco de sorte e o seu gerente ainda te deu tempo para configurar todo esse ambiente (open source gratuito né?), agora você tem um ambiente minimamente respeitável. Você possui ferramentas para fazer testes unitários, testes web, cobertura de código, possui um relatório simples sobre o resultado dos seus testes, uma ferramenta para explorar cobertura dos seus testes e possui também a integração com build. Muito Bom! Será que agora dá pra comparar com o VSTE?

Para as tarefas mais comuns, como as citadas acima, nós vimos que realmente temos boas alternativas no mundo open source, mas quando falamos de ALM, nós estamos buscando algo mais, além de testar, queremos métricas para avaliar e melhorar nosso processo, queremos produtividade sem perder a qualidade e para isso, integração é fundamental. Não dá pra tratar testes de software com ferramentas isoladas em um ALM de verdade.

Vamos imaginar então que na sua empresa você tenha alguns relatórios que mostram quantos bugs estão abertos, a situação atual da build e até quantos testes foram executados na ultima build, mas você não tem nenhum histórico disso. Além de não ter histórico, esses relatórios são gerados por ferramentas diferentes e você não consegue cruzar as informações e saber o real status da qualidade do seu projeto. Você também não sabe se está melhor ou pior do que estava há um mês. Enfim, você tem um monte de pedaços de informação que não te ajuda em muita coisa. Infelizmente, este é um cenário bastante comum no mundo open source! Porém, você ainda pode customizar as ferramentas, mas aí já não dá mais pra dizer que é gratuito.

Agora vamos imaginar um relatório onde você possa visualizar a qualidade do seu projeto build a build, onde num determinado período você veja as builds geradas, a quantidade de testes que foram executados, a quantidade de testes que tiveram sucesso ou falharam, vamos supor ainda que você possa ver neste mesmo relatório o índice de code coverage por build além do número de bugs abertos em cada build. Fantástico, não? Esse relatório é o Quality Indicators e está disponível no VSTS sem que você precise coletar dados para gerá-lo, basta usar a ferramenta no dia a dia que em algumas semanas você terá um panorama completo da qualidade do seu projeto.

Imagem 3: Relatório de Quality Indicators do VSTS

Ainda com as comparações, quando estudamos a disciplina de ALM, vimos que ela é muito mais abrangente do que a simples construção do software, ela engloba governança, engloba operações de TI e como o próprio nome diz, todo o ciclo de vida da aplicação tem que ser gerenciado, incluindo evoluções futuras, melhorias de performance, etc.

Vamos pensar num outro cenário então onde ajustes de performance sejam necessários em uma aplicação que já está pronta. Vamos pensar numa aplicação de uma grande loja virtual hospedada em vários servidores, que após um determinado número de usuários, o tempo de resposta fica muito ruim. Como resolver esse problema?

Antes de sairmos adicionando mais servidores, processadores, memórias e discos mais rápidos, precisamos identificar onde está o gargalo. Mas como fazer isso? Talvez um teste de carga pudesse nos ajudar, correto?

Com o Visual Studio Test Edition, você pode fazer esse teste de carga. Na verdade, você pode ir muito mais além, você pode por exemplo coordenar 50 computadores ociosos para fazer um teste de carga realmente pesado. Além disso, você pode monitorar todos os contadores de todos os servidores utilizados pela aplicação e identificar exatamente o ponto gargalo dela. Chegando a descobrir que o primeiro erro de HTTP 404 ocorreu com 15 minutos de teste, com uma carga de 10.000 usuários simultâneos, o que elevou o processador do seu SQL Server a 100%, por causa do uso intenso de da procedure XYZ. Muti bom né? Eu sinceramente desconheço uma ferramenta open source que me ofereça isso.

Imagem 4: Relatorio do Teste de Carga do Visual Studio Test Edition

O mais curioso é que mesmo após citar todas essas features fantásticas do produto, às vezes eu ainda ouço coisas do tipo: “Poxa André, tudo isso é muito legal, mas eu não preciso disso. ”. Ok, talvez você realmente não precise ter uma visão panorâmica da qualidade do seu produto e talvez não tenha cenários onde poderia tirar proveito de tudo que foi mostrado até agora, mas será que ainda assim o Visual Studio Test Edition oferece vantagens em relação as ferramentas Open Source? Adivinhem a resposta :-)

Testes Manuais

Sabemos que boa parte dos testes realizados ainda hoje, infelizmente, são manuais. Então, já que temos que conviver com isso, porque não gerenciá-los, versioná-los, extrair relatórios de testes manuais, saber quais testes manuais já foram realizados. Isso mesmo, incluí-los no ALM. Acho que nem preciso dizer que fazer isso com o VSTS, é moleza, correto?

Imagem 5: Ambiente de execução de testes manuais

Testes Unitários e Cobertura de Código

Neste momento você deve estar pensando: “Tá bom André, eu conheço muito bem o NUnit e NCoverage e quero ver você falar que o VSTS oferece alguma vantagem sobre eles”. É realmente você está certo, este é um ponto onde as ferramentas open source ficam bastante próximas do VSTS, porém ainda falta alguma coisa! Falta a integração e eu não estou falando da integração com a IDE, que por sinal já me dá um grande aumento na produtividade, estou falando novamente da integração no ALM.

Pessoal, é difícil competir com uma ferramenta tão integrada como o VSTS! O NUnit vai executar os meus testes? Sim! O NCoverage vai mostrar o índice de cobertura de código? É claro que vai. O que eles não vão oferecer é uma integração dos work items com esses resultados. E com isso eu não poderei criar um bug a partir do teste que falhou. E Conseqüentemente, não vou ter a rastreabilidade que o VSTS me oferece, me permitindo saber, por exemplo, que para concluir um determinado Caso de Uso, foram utilizadas 40 horas mais 3 correções de bugs que me geraram mais 16 horas e ter uma visão geral das horas utilizadas para concluir o caso de uso.

Sei que é triste, mas ainda não foi dessa vez que o open source ganhou do VSTS, mas bateu na trave. :-)

Imagem 6: Ambiente de execução de testes unitários com cobertura de código

Testes Web

Quando me falam desse tipo de teste, eu me lembro de uma aplicação que desenvolvi no início de minha carreira para uma empresa de RH onde parte da aplicação era um mega formulário para o usuário digitar o currículo dele. Um formulário cheio de validações, onde tínhamos que entrar com os dados corretamente para testá-lo e quando você clicava no submit e recebia uma tela de erro era um momento desesperador. Todos os dados perdidos e tínhamos que preencher todos os campos novamente desde o início.

Por que eu contei toda essa historinha? Simplesmente porque quase fiquei traumatizado e com LER nessa época e se eu tivesse o VSTE, todos os meus problemas estariam resolvidos :-)

Claro que isso é uma brincadeira para descontrairmos um pouco no final deste artigo, mas ela serve também para ilustrar um uso bastante interessante do teste web que te permite navegar por uma aplicação, gravar centenas de macros, salvá-las como testes web e reproduzi-las quantas vezes desejar inclusive fazendo uma integração com o servidor de build para execução destes durante o build.

Imagem 7: Ambiente de execução de testes web do VSTS

Bom pessoal, com isso nós finalizamos a primeira parte desta série, onde o meu objetivo era justamente mostrar a grande diferença que há entre o NUnit e o Visual Studio Test Edition e como pudemos ver fica até difícil estabelecer uma comparação justa devido a enorme diferença entre os produtos.

Procurei apresentar também as principais funcionalidades do Visual Studio Test Edition 2008, já que muita gente tem o produto e não conhece todo o potencial dele e já aproveito para adiantar que a versão 2010, com previsão de lançamento para o 1o. trimestre de 2010, está ainda melhor com uma nova ferramenta de testes independente do Visual Studio, gerenciamento de máquinas virtuais para testes, testes de aplicações Windows, enfim. Muita coisa nova vindo por aí.

Em breve, mais um artigo comentando sobre as outras funcionalidades do VSTS em relação a ferramentas open source.

Abraços e até a próxima.
André Dias