Temple Coding

Já ouvi e li muita gente dizer que um bom código é subjetivo, sujeito a interpretação e coisas do gênero. Eu acredito que alguns aspectos do código podem ser definidos de uma forma mais prática e não tão subjetiva.

É claro, os padrões de projeto que usamos, as linguagens, quantidade de linhas que tem um método, essas coisas são realmente subjetivas e devem ser analisadas de acordo com o projeto/cliente/equipe, etc.

Mas quando eu codifico eu tenho algumas regras, que acredito que sejam bem claras, que ajudam a definir um bom código, claro, não são as únicas, mas essas são as primeiras que eu tomo por padrão. Pra mim um bom código começa com:

1) Dar um bom nome

Um classe, método ou variável deve ter um nome que documente e principalmente determine o que faz. Se você tiver uma classe que chama Gerenciador e um método chamado Executar, você está abrindo o escopo do que a classe e método podem fazer. O nome não restringe e pior não indica nada que o código deve fazer. Classes e métodos devem ter um próposito único e o nome deve refletir esse propósito.

Da mesma forma uma váriavel que chama simples “data” ou “valor” não dizem muita coisa. Prefira um nome como dataNascimento ou valorFaturado.

2) Códigos devem ser de fácil manutenção/modificação

Existe uma razão muito simples porque eu não concordo com a metáfora da construção civil para o desenvolvimento de software. Se você se sente quebrando uma parede quando está alterando ou adicionando uma melhoria para sua aplicação, com certeza você fez alguma coisa errada.

Existem diversos padrões de projetos e princípios que nos ajudam a fazer códigos que são mais fáceis de se manter. Comece sempre evitando repetições, se quando você tem que alterar uma funcionalidade, tem de mexer em mais de um local, provavelmente existe uma solução melhor pra isso.

Mas acima de tudo use o que a orientação a objeto tem de melhor para facilitar a alteração do sistema, afinal de contas, qual foi o projeto que você fez do início ao fim e que não teve nenhuma modificação?

3) Testes, testes e mais testes

Na verdade esse item poderia ser um complemento do anterior, testes ajudam a dar segurança e credibilidade na manutenção do código. Honestamente, eu não consigo mais me ver escrevendo um código novo sem teste unitário. O simples fato de fazer uma alteração e saber que nada quebrou porque tenho testes unitários já me convence de que eu preciso deles.

Conclusão

São 3 regras simples, somente elas não garantem um bom código, com certeza não. Mas para mim essas são as 3 regras que iniciam o desenvolvimento de um bom código, não consigo me ver escrevendo código sem pensar nessas regras e principalmente não acredito que um desenvolvedor que se considere sênior, seja realmente sênior se não tem essas 3 regras básicas.

E pra você, quais são as suas regras?

House Arguing from Thiago Temple on Vimeo.

Eu sou um fã do seriado House M.D., não é de hoje, existem muitas coisas nesse seriado com as quais me identifico, mas uma das coisas que eu sempre curti, embora tenha que admitir, eu nunca entendo a parte técnica, são as discussões que eles fazem quando estão em um diagnóstico diferencial.

Veja só, na maioria das vezes, não só o House, como os outros médicos discutem e propõem idéias, sempre com base em seus conhecimentos e em exames médicos, a impressão que você tem ao assistir essas discussões é de que eles sabem do que estão falando. Claro, eu sei que é só uma ficção, mas por favor, não estrague o meu prazer de assistir o seriado

Existem duas analogias que quero fazer em relação a isso.

Primeiro os exames médicos. Para que eles possam evoluir no diagnóstico que estão fazendo eles fazem exames, eles não saem abrindo o paciente (pelo menos não na maioria das vezes). O que quero dizer com isso é, não é só usando o debugger que resolvemos problemas, isso, geralmente é um sinal de um software mal feito. Veja, podemos escrever logs, podemos rodar testes unitários, podemos fazer uma análise de DUMP de memória. Debugar, principalmente quando falamos de um sistema que roda na web deveria ser a última opção. Quando for escrever seu próximo sistema, pense que você deve gerar logs com o máximo de informação relevante para resolver algum problema futuro.

Em segundo lugar, eles sabem do que estão falando, tem conhecimento sobre o assunto, nesse caso obviamente percebemos principalmente com o House, mas os outros médicos sabem do que estão falando também. E o que quero dizer aqui pode parecer óbvio, mas não é o que vejo em muitos casos. Quando for resolver um problema ou desenvolver uma nova solução ou simplesmente dar continuidade em um projeto, tente entender porque aquilo funciona daquele jeito, conheça porque aquela tecnologia funciona e não somente “tá funcionando, não põe a mão”.

Como programadores muitas vezes buscamos uma solução para um problema na internet, copiamos um código, colamos no projeto e pronto. Funcionou? Sim, então tá bom. Não! Não está bom, saiba porque aquilo funciona, porque se tiver algum problema é você que terá que corrigir.

Finalmente, quero concluir dizendo que você não é um especialista em uma tecnologia (digamos Java ou .NET), porque você não conhece outra, você é um especialista em uma tecnologia quando você conhece profundamente aquela tecnologia. Dizer que você é um especialista em .NET porque você nunca programou em Java, não faz você saber como funciona o gerenciamento de memória do .NET Framework.

Eu acho que nunca vou cansar de falar sobre isso, sobre o quanto acho isso importante. Não é porque você gosta da tecnologia X ou Y que você não precisa conhecer a Z. Não é porque você sempre fez de um jeito que aquele jeito está certo. Me dói ver pessoas defendendo metodologias e tecnologias sem nem se dar ao trabalho de conhecer outras coisas para saber o que estão criticando.

Ainda bem, as coisas sempre evoluem, tecnologias melhoram, tornam nosso trabalho mais fácil. Só para dar dois exemplos:

1) Eu sempre fiz aplicações web se comunicarem com o SAP através do .NET Connector, até que um dia eu tive que usar o Java Connector para comunicação com o SAP, e tenho que dizer, como o JCO é melhor! Mais fácil, máis prático, eu passei a fazer tudo de uma forma muito mais simples.

2) Eu sempre participei de projetos usando as metodologias tracidicionais, cascata, mais rígidas, por assim dizer, e sempre achei que era a melhor coisa que existia, não porque eu realmente acredidava naquilo, mas porque eu não conhecia o outro lado. Um belo dia, meu amigo Sérgio Monteiro me apresentou um tal de SCRUM e posso dizer que tive um pouco de resistência, mas não demorou muito e cá estou eu, defendendo o SCRUM e principalmente o Ágil onde quer que eu vá.

O que eu quero dizer é: não vista a camisa de uma plataforma/tecnologia só por vestir, primeiro que você nunca sabe quando o fabricante ou responsável por isso vai mudar de idéia, segundo, o mercado de software é muito novo e portanto está evoluindo muito rapidamente e aquilo que parecia bom ontem pode não ser o melhor hoje.

Liderar ou gerenciar um time não é uma tarefa fácil, não é a toa que vemos tantos livros sobre liderança. Muitas vezes caímos no risco de querer controlar tudo o que os liderados/gerenciados fazem, o que pode ser conhecido como micro gerenciamento. Isso, claro, pode acontecer porque não confiamos no julgamento ou capacidade alheia, mas também pode ser pela crença errada de que quanto mais informações tivermos, melhor poderemos tomar uma decisão.

Paul Van Riper, ex-comandante de um batalhão no Vietnã disse:

“Um comandante não precisa saber a pressão barométrica, os ventos ou mesmo a temperatura. Ele precisa saber a previsão. Se você se envolver demais na produção de informações irá se afogar nos dados.”

Quando eu li essa citação, não pude deixar de ligar com várias experiências que já tive, sendo um líder ou sendo liderado. Não precisamos saber os mínimos detalhes técnicos para saber se algo vai dar certo ou não, precisamos primeiro de tudo confiar nos nossos liderados. Ou então, teremos que tomar muito mais decisões do que realmente precisamos. Além do mais, existem diversos estudos que comprovam que precisamos de bem menos informações para tomar uma decisão do que realmente acreditamos.

Quanto mais informações exigimos, ou melhor, em quanto mais detalhes tentamos nos envolver, mais burocráticos e lentos nos tornamos. Citando novamente Van Riper:

“É como As viagens de Gulliver, o gigante é amarrado por aquelas pequenas regras, regulamentos e procedimentos. E o baixinho? Ele simplesmente dá a volta e faz o que quer.” 

Delegar não é uma tarefa fácil, por isso é uma das questões mais exploradas quando se fala em liderança, mas com certeza vale o esforço.

Apenas para contextualizar, Van Riper participou de um treinamento no Pentágono em 2002 chamado de O Desafio do Milênio, onde ele liderava uma equipe, chamada de equipe vermelha que enfrentava a equipe azul. A idéia era fazer uma simulação de uma guerra do golfo para poder testar um time todo informatizado.

A equipe azul tinha diversos estudos, acesso a várias informações e um programa de computador que equacionava informações militares, políticas e econômicas do inimigo. Antes de disparar um tiro, ou tomar uma iniciativa a equipe azul devia trocar mensagens e discutir cada decisão com seu comando.

Van Riper, chamou para sua equipe corretores de Wall Street que estavam acostumados a tomar decisões rápidas com poucas informações. E dispunha de um aparato militar comum.

O resultado do desafio? No segundo dia desse desafio, enquanto a equipe azul discutia com seus comandantes as ações que devia tomar, Van Riper apenas disse ao seus comandados o que ele queria e não como, a equipe vermelha atacou a equipe azul de surpresa e destruiu 16 navios dos azuis.

Por que isso deu certo com a equipe de Van Riper? Posso dizer duas coisas que vem à mente e que podemos usar para o mundo do software.

1) Quem está executando a atividade ou no caso de Van Riper, quem estava no campo de batalha, consegue ou deve conseguir tomar as decisões mais rápidas e eficientes para executar aquela tarefa da maneira mais eficiente. São essas pessoas que estão vendo o problema no momento que tem cada detalhe.

2) Liberar um líder de cada detalhe permite que ele tenha tempo para ter a visão geral e determinar a melhor estratégia de forma macro.

Apenas para finalizar, vale dizer que Van Riper, além disso, permitiu que seus comandados fossem criativos para tomar suas decisões sem que esses mudassem o rumo da missão, ele criou as condições para a espontaneidade bem-sucedida.

Anteriormente eu falei sobre builds automáticos com o MSBuild, bem, se você levar ao pé da letra, os builds feitos de acordo com aquele post não eram exatamente automáticos, o que acontecia de forma automática no momento em que o build era executado eram os testes unitários e a análise de cobertura de código feita pelos testes unitários. Agora, eu vou falar sobre como integrar isso com o Cruise Control .NET que é uma ferramenta de Integração Contínua.

Sobre Integração Contínua

Eu não vou parar e explicar aqui sobre integração contínua, acredito que uma ótima fonte é o texto do Martin Fowler traduzido pelo Pedro Mendes e que pode ser encontrado aqui.

Apenas como um resumo: integração contínua é uma prática, ou melhor, um conjunto de práticas que visa, entre outras coisas, detectar problemas no código o mais rápido possível para que esse código se integre a um repositório de código compartilhado por outros desenvolvedores.

Algumas dessas práticas são:

• Possuir um repositório central para o código
• Realização de builds automáticos
• Check-in ou commit do código frequentemente
• Testes executados de forma automática
• Que todos os participantes tenham uma visualização do código

Como disse, esse é apenas um resumo, eu recomendo fortemente que você leia o texto indicado acima.

O Cruise Control .NET

O Cruise Control .NET é uma ferramenta open source para implementação de integração contínua. Obviamente não é única, mas é uma das mais conhecidas no mercado juntamente com as irmãs Cruise Control (feita em java) e Cruise Control rb (feita em ruby). Segue aqui um link para baixar o Cruise Control .NET.

A instalação é bem simples, as únicas observações são que após a instalação deve-se definir uma senha para o administrador do dashboard, para isso vá até a pasta onde está instalado o Cruise Control NETwebdashboard e abra o arquivo dashboard.config e altere a configuração com a senha escolhida:

1

<administrationPlugin password="" />

Além disso é preciso dar permissão de escrita no arquivo dashboard.config e na pasta xls para o usuário IUSR_XXX, onde XXX é o nome da máquina onde você está realizando a instalação do Cruise Control.

Após a instalação do Cruise Control, um serviço é adicionado ao windows que precisa ser iniciado.

Configurando o Cruise Control .NET

Antes de colocar um projeto CCNet vamos configurá-lo para exibir os dados que gostaríamos que são os dados do MSBuild, do NUnit e do NCover. Se você fez uma instalação padrão deve acessar o dashboard pelo endereço http://localhost/ccnet

Clique em Administer Dashboard, entre com a senha configurada para o administrador e você deve ver uma lista com os Packages disponíveis. Instale os 3 que vamos usar clicando em cada um deles, MSBuild Results, NCover Results e NUnit Results.

Configurando um novo projeto no Cruise Control

Configurar um projeto no Cruise Control é editar um arquivo XML, não é muito amigável mas é de certa forma bem simples. O arquivo que vamos editar é o ccnet.config que fica na pasta server onde foi instalado o CCNet.

Estou usando o projeto do post anterior sobre o MSBuild e configurando ele no CCNet. Primeiro, estou assumindo que você tem o seu projeto em um repósitorio, no meu caso, estou usando o Subversion, mas o CCNet suporta diversos.

Veja como ficou configurado o meu arquivo ccnet.config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
    <project>
        <name>MSBuildDemo</name>
        <triggers>
            <intervalTrigger />
        </triggers>
        <workingDirectory>c:CCNetWorkingMSBuildDemo</workingDirectory>
        <artifactDirectory>c:CCNetArtifactsMSBuildDemo</artifactDirectory>
        <modificationDelaySeconds>2</modificationDelaySeconds>
        <sourcecontrol type="svn">
            <trunkUrl>http://localhost:8181/svn/blog/MSBuildDemo</trunkUrl>
        </sourcecontrol>
        <tasks>
            <msbuild>
                <executable>C:WINDOWSMicrosoft.NETFrameworkv3.5MSBuild.exe</executable>
                <projectFile>MSBuildDemo.proj</projectFile>
                <buildArgs>/p:Configuration=Debug /v:diag</buildArgs>
                <targets>CoberturaTestestargets>
                <logger>C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
            </msbuild>
        </tasks>
        <publishers>
            <merge>
                <files>
                    <file>c:CCNetArtifactsMSBuildDemo*ResultadosTestes.xml</file>
                    <file>c:CCNetArtifactsMSBuildDemo*ResumoCobertura.xml</file>
                </files>
            </merge>
            <xmllogger />
        </publishers>
    </project>
</cruisecontrol>

Vamos por partes.

Na linha 3 definimos o nome do projeto.

Na linha 4 definimos o que o CCNet usará para determinar se deve ou não executar as atividades do projeto, no caso do nosso exemplo, o CCNet irá, em um intervalo de tempo, verificar se existe alguma modificação no repositório, e se houver, executar as atividades.

Na linha 7 definimos uma pasta onde o CCNet vai baixar os arquivos do repositório e compilar os projetos.

Na linha 8 definimos uma pasta onde o CCNet irá salvar os arquivos que serão gerados como produto da compilação, como os relatórios do NUnit e do NCover.

Das linhas 10 a 12 definimos os dados do repositório, nesse caso o subversion.

Das linhas 13 a 21 definimos as tarefas, nesse caso, que a compilação será executada pelo MSBuild, onde está o executável do MSBuild, o script do MSBuild que deve ser executado, qual o target do MSBuild e logger que será usado para as atividades do MSBuild.

Por último das linhas 22 a 28 definimos quais arquivos gerados pelo script do MSBuild devem ser usados para gerar os relatórios do CCNet.

Se der tudo certo, ao acessar o dashboard você deve ver algo como:

Clique em MSBuildDemo e você deverá ver as compilações já feitas, e pode clicar nas compilações e ver os detalhes. O importante é que a partir de agora a cada vez que for realizado um novo check-in o CCNet irá perceber que existe uma alteração e executará o script do MSBuild que definimos novamente.

Alterando o script do MSBuild

Se você está seguindo o exemplo feito no post anterior, precisamos fazer algumas alterações no script do MSBuild. Precisamos apenas alterar o script para que salve os arquivos do NUnit e do NCover na pasta de artefatos definida no XML que configuramos o projeto do CCNet. Quanto um script do MSBuild é executado pelo CCNet uma variável CCNetArtifactDirectory é definida com o caminho da pasta de artefatos então a tarefa do NCover ficou assim:

1
2
3
4
5
6
7
8

<NCover ToolPath="$(CaminhoNCover)"
        CommandLineExe="$(ComandoNUnit)"
        CommandLineArgs="$(TestFolder)bin$(Configuration)UnitTests.dll"
        WorkingDirectory="$(TestFolder)bin$(Configuration)"
        CoverageFile="$(CCNetArtifactDirectory)$(ArquivoNCover)"
        LogFile="$(ArquivoLogNCover)"
        ExcludeAttributes="MSBuildDemo.Common.CoverageExcludeAttribute"
        AssemblyList="@(CodeProjects->'%(FileName)')" />

E as tarefas do NCover Explorer ficaram assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<NCoverExplorer ToolPath="$(CaminhoNCoverExplorer)"
    ProjectName="$(ProjectName)"
    OutputDir="$(CCNetArtifactDirectory)"
    CoverageFiles="$(CCNetArtifactDirectory)$(ArquivoNCover)"
    SatisfactoryCoverage="80"
    ReportType="3"
    XmlReportName="ResumoCobertura.xml"
    HtmlReportName="ResumoCobertura.html" />
<NCoverExplorer ToolPath="$(CaminhoNCoverExplorer)"
    ProjectName="$(ProjectName)"
    OutputDir="$(CCNetArtifactDirectory)"
    CoverageFiles="$(CCNetArtifactDirectory)$(ArquivoNCover)"
    SatisfactoryCoverage="80"
    ReportType="4"
    XmlReportName="RelatorioCoberturaPorClasse.xml"
    HtmlReportName="RelatorioCoberturaPorClasse.html" />

E as tarefas do NUnit foram alteradas assim:

1
2
3
4
5
6
7
8
9

<CreateItem Include="$(CCNetArtifactDirectory)*.$(ArquivoNUnit)">
    <Output TaskParameter="Include" ItemName="ExistingNUnitResults"/>
</CreateItem>
 
<Delete Files="@(ExistingNUnitResults)"/>
 
<Copy SourceFiles="@(NUnitResults)"
    DestinationFolder="$(CCNetArtifactDirectory)"
    ContinueOnError="true"/>

Um detalhe importante é que os nomes dos arquivos gerados pelo NUnit e pelo NCover devem ser iguais aos nomes dos arquivos dentro da tag files no projeto configurado dentro do ccnet.config.

Utilizando o CCTray

O CCTray é um aplicativo que instalamos e ele fica constantemente consultando o servidor do CCNet e nos avisa se algum build ou teste unitário foi quebrado. No dashboard do CCNet tem um link para fazer download do CCTray e novamente a instalação é muito simples.

A configuração dele também é simples, após instalado, vá em File -> Settings -> Build Projects clique em Add para e depois em Add Server, aponte para o endereço onde está instalado o servidor depois em OK, agora é só selecionar o seu projeto.

Customizando os relatórios do NCover Explorer

Quando você baixa o NCover Explorer Extras, dentro do zip existe uma pasta Cruise Control .NET, copie os arquivos .xls que estão nessa pasta para a pasta webdashboard/xls onde foi instalado o seu CCNet.

Depois a abra o arquivo dashboard.config e edite para que fique assim:

1
2
3
4
5
6
7

...
<xslFileNames>
    ...
    <xslFile>xslNCoverExplorerSummary.xslxslFile>
    ...
</xslFileNames>
<xslReportBuildPlugin description="NCover Report" actionName="NCoverBuildReport" xslFileName="xslNCoverExplorer.xsl" />

Entre no dashboard e clique em Force Build, depois que o build estiver completo e você entrar pelo dashboard nesse último build, você deverá ver um relatório como o abaixo:

Conclusão

Pronto, agora sim você tem um projeto que é compilado automaticamente a cada check-in/commit, os testes unitários são executados também de forma automática e se por acaso o projeto parar de compilar ou algum teste unitário falhar o CCTray avisará com uma mensagem e inclusive fará o trabalho de dedo duro dizendo quem foi o usuário que fez o último commit com a falha.

O ideal é que todos do projeto tenham o CCTray e que a primeira, ou uma das primeiras atividades seja configurar o script para compilação automática.

Com isso você pode ter mais certeza, a cada commit, que seu código não irá causar problemas a outros e se causar, você terá uma resposta imediata, o que torna a correção do problema muito mais fácil.

No meu post anterior sobre build automático com MSBuild e NCover e usei uma opção do NCover chamada ExcludeAttributes como pode ser visto na linha 7 abaixo:

1
2
3
4
5
6
7
8

<NCover ToolPath="$(CaminhoNCover)"
    CommandLineExe="$(ComandoNUnit)"
    CommandLineArgs="$(TestFolder)bin$(Configuration)UnitTests.dll"
    WorkingDirectory="$(TestFolder)bin$(Configuration)"
    CoverageFile="$(ResultsFolder)$(ArquivoNCover)"
    LogFile="$(ArquivoLogNCover)"
    ExcludeAttributes="MSBuildDemo.Common.CoverageExcludeAttribute"
    AssemblyList="@(CodeProjects->'%(FileName)')" />

O que isso quer dizer e por que isso importa?

Isso importa porque, nem todo o código que temos em nossos projetos vamos querer testar e porque esse código pode atrapalhar a métrica de percentual de código coberto pelos testes.

Usando como exemplo o projeto que fiz no modelo anterior que pode ser visto aqui, podemos ver que em todo projeto ASP.NET MVC algumas classes são criadas automaticamente e essas classes não precisam ser testadas (assumindo que elas funcionam e não vamos modificá-las). Outro exemplo que temos nesse projeto, são as classes geradas automaticamente pelo LINQ to SQL para mapear a base de dados.

Como resolver?

Para resolver esse problema eu criei a classe MSBuildDemo.Common.CoverageExcludeAttribute e configurei na tarefa do NCover como visto acima. Veja como ficou a classe:

1
2
3
4

[AttributeUsage(AttributeTargets.All)]
public sealed class CoverageExcludeAttribute : Attribute
{
}

Bem simples não? Agora é só colocar esse atributo nas classes ou métodos que não queremos contar para a cobertura do código. Como nesse exemplo, veja a linha 2:

1
2
3
4
5
6

[HandleError]
[CoverageExclude]
public class AccountController : Controller
{
    // ...
}

O MSBuild é a ferramenta da Microsoft usada em conjunto com o Visual Studio para compilar os projetos. Toda vez que compilamos um projeto no Visual Studio (a partir da versão 2005 pelo menos), o que acontece é que o VS chama o MSBuild para executar a tarefa de compilar os projetos da solução.

O bom disso é que podemos customizar a compilação/deploy para executar diversas tarefas nesse momento, entre essas atividades existem algumas como zipar o projeto compilado, enviar por email, publicar no IIS, etc. Mas eu queria falar sobre duas que tenho usado que são: executar os testes unitários e executar uma ferramenta de cobertura de código para ver qual a porcentagem de código coberto pelos testes unitários.

O projeto demo

Para começar, criei um solução usando o ASP.NET MVC, com um componente para acesso a dados separado do projeto de Web. Apenas como forma de mostrar o MSBuild compilando projetos diferentes.

O projeto é bem simples, a idéia mesmo é conectar no intergalaxialmente famoso banco de dados Northwind e exibir os dados da tabela de categorias. Uau!!! Uma tarefa que consumirá horas, mas, como eu disse o foco é mostrar um pouco do funcionamento do MSBuild. O código da aplicação está disponível aqui.

Pré-requisitos

O MSBuild é instalado junto com o Visual Studio, mas existem algumas coisas que você vai precisar para rodar esse demo. Espero que você já tenha o NUnit instalado, eu estou usando a versão 2.5.3. Além do NUnit você vai precisar:

• NCover – eles pedem um cadastro e existem versões pagas, mas a versão 1.5.8 é gratuita e serve para os nossos propósitos.
• NCoverExplorer – para gerar um relatório mais amigável do NCover.
• NCoverExplorer Extras – possui tarefas customizadas para o MSBuild executar o NCoverExplorer.
• MSBuild Community Tasks – tarefas customizadas feitas para o MSBuild.

O NUnit, NCover e o MSBuild Community Tasks possuem instaladores próprios.O NCoverExplorer e o NCoverExplorer Extras são um pouco diferentes. O NCoverExplorer não precisa de instalação, por isso eu já inclui dentro do zip com o código, na pasta tools.

Quando você baixar o NCoverExplorer Extras terá uma pasta zip e dentro dela uma dll chamada NCoverExplorer.MSBuildTasks.dll, eu, apenas por uma questão de organização criei uma pasta c:Program FilesNCoverBuild Task Plugins e copiei essa dll lá dentro.

Pronto, isso é tudo o que é necessário para rodar o MSBuild.

Entenda o arquivo do MSBuild

Depois de baixar, olhar o código e os testes unitários abra o arquivo MSBuildDemo.proj.

O arquivo MSBuildDemo.proj nada mais é do que um arquivo xml. Então vamos começar a entendê-lo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

 
        MSBuildDemo.sln 
        $(MSBuildProjectDirectory) 
        $(MSBuildProjectDirectory)testsUnitTests 
        $(MSBuildProjectDirectory)Results 
        Debug 
        AnyCPU 
 
        C:Program FilesNUnit 2.5.3binnet-2.0M 
        $(CaminhoNUnit)nunit-console.exe 
        ResultadosTestes.xml 
        C:Program FilesNCover 
        ResultadoNCover.xml 
        Coverage.log 
        $(MSBuildProjectDirectory)toolsNCoverExplorer 
 
    ...

Primeiro, veja que na linha 9 apontamos para a nossa dll instalada pelo MSBuild Community Tasks.

O resto do código acima é bem fácil de entender, estamos definindo variáveis que vamos usar depois nas tarefas de deploy, algumas coisas que valem mencionar.

• Definição do arquivo .sln na linha 12
• Definição dos caminhos das ferramentas no bloco que vai da linha 20 a 28

Agora precisamos identificar os projetos da solução que serão compilados e os projetos de testes, faremos assim:

1

Vale mencionar aqui que a propriedade ItemName de cada tag Output é uma váriavel criada que pode ser utilizada depois.

Basicamente estamos buscando todos os projetos da solução, usando uma Expressão Regular para encontrar os Projetos que tenham a palavra Test ou IntegrationTest para encontrar os projetos de testes e separando os dois tipos de projetos.

Agora vamos compilar os projetos que não são testes.

1

E agora compilamos os projetos de Testes

1

E a última etapa é rodar o NCover e o NCoverExplorer

1

No código acima mandamos gerar dois relatórios e, entre outras coisas, definimos que queremos que nosso código tenha 80% de cobertura.

Pronto, temos aqui um script para compilar, executar os testes e a cobertura de testes. Agora, como rodamos isso?

Abra o Visual Studio Command Prompt, pra quem não sabe, veja onde ele está:

Vá até a pasta onde está o arquivo MSBuildDemo.proj e digite MSBuild MSBuildDemo.proj

Se você executar isso, os projetos serão apenas compilados porque no início do script definimos como atividade padrão a target Build.

  1: DefaultTargets="Build"

Targets, são tarefas ou conjuntos de tarefas que podem ser definidas. Queremos executar a tarefa CoberturaTestes, porque se você prestar atenção no script ela depende da tarefa Tests que por sua vez depende de BuildTests que depende de Build, ou seja executando CoberturaTestes todo o script será executado, então rode o comando:

MSBuild MSBuildDemo.proj /target:CoberturaTestes

Se tudo der certo e sob as condições ideais de temperatura você deve ver algo como:

Além disso, de acordo com nosso script foi criada uma pasta dentro do diretório da solução chamada Results, ali você pode ver o resultado da cobertura de testes. Abrindo o arquivo RelatorioCobertura.html veremos:

Além disso, se você olhar um pouco mais acima na tela do prompt verá o resultado da execução dos testes unitários:

Pronto, seus testes unitários são sempre executados e você já sabe quanto falta para testar seu código.