Ontem ocorreu o primeiro Coding Dojo do grupo DotNetFloripa. Acabei não anunciando aqui no blog (a lista de dois grupos me pareceu uma audiência um pouco maior ), mas ao menos os resultados ficarão registrados por aqui.

A idéia do dojo surgiu numa troca de e-mails em que discutíamos possíveis temas de futuros eventos do grupo e, como eu nunca havia ouvido falar da expressão (vcs realmente já haviam? ), saí pesquisando pelo Google, seguindo links, aquele processo habitual. Também habitualmente metido, enviei algumas sugestões e acabei abraçando a organização desse primeiro encontro. Muito gratificante!

Não compareceram muitas pessoas (8 no total), o que acabou mostrando-se positivo no final do encontro. A interação e participação de todos ocorreu acima do esperado (pelo menos por mim), o que foi um dos pontos fortes do evento. Estava com um pé atrás pois nas reuniões do grupo que participei a interação do pessoal com o palestrante, no geral, não era das mais eloquentes. Nesse encontro, entretanto, todos contribuíram com idéias para o código, dúvidas e tudo mais. Como boa parte do pessoal ainda não utiliza TDD no dia a dia, boa parte do tempo foi utilizada discutindo alguns conceitos, explicando outros, etc, etc. Por este motivo acabamos não tendo tempo para concluir o problema, mas espero que não faltem próximas oportunidades.

No final, chegamos a uma lista de pontos positivos e outros que podemos melhorar para os próximos encontros:

Pontos positivos:

• Número de participantes: mesmo não plenejadamente, foi consenso entre todos que um número de participantes maior que 10 pode inviabilizar a interação no dojo;
• Prova do TDD: mesmo não tendo codificado tanto quanto deveríamos (construímos 4 métodos de teste) já foi possível exemplificar o valor do TDD quando, devido à alteração para um teste, outro anteriormente “green” passou a falhar;
• Participação do pessoal: todos interagiram e sentaram-se pra programar, sem medo de ser feliz. Dicas de VS, frameworks, TDD, lógica e dúvidas surgiram aos montes. Muito legal;

Pontos a melhorar:

• Conceituação de TDD: pela pouca experiência de parte do pessoal com TDD, a maior parte do tempo foi utilizada em conceito ao invés de programação. Apesar de também ser positivo, o ideal seria fazermos uma palestra sobre TDD para que pudéssemos simplesmente praticá-lo no Dojo (obs.: a palestra já está sendo agendada);
• Tempo de cada piloto: não houve um controle do tempo que cada um passava programando, o que dificultava as trocas num tempo “justo”. Foi sugerido que utilizemos uma abordagem “ping pong”, onde um desenvolvedor implementa um teste falho e o próximo faz o teste corrigir. Muito válido;
• Piloto “type only”: em mais de uma situação a pessoa que estava programando simplesmente digitava o que os outros iam falando, não dando oportunidade ao piloto e ao co-piloto de decidirem por um passo antes de serem questionados. Talvez o ideal seja dar mais autonomia ao piloto/co-piloto (definição do próximo teste falho, por exemplo) para depois virem sugestões, questionamentos e tudo mais;
• Resolução do problema: não conseguimos resolver o problema dentro do tempo previsto, se na próxima deixarmos ele sobreviver novamente vai virar questão de honra..

Se alguém quiser ver o PPT com a descrição do problema que tentamos resolver + conceitos de Dojo e TDD + código desenvolvido, coloquei tudo no RapidShare pra baixar. É só clicar aqui. Abaixo segue uma das fotos tiradas por lá do pessoal interagindo:

Gostaria de agradecer ao pessoal do DotNetFloripa que compareceu no encontro pela presença e interação, ao pessoal do DojoFloripa pelo feedback positivo e representação (1 dos participantes era de lá! ) e ao Ivan Sanchez (ex-DojoFloripa, atualmente em Londres) que me ajudou a esclarecer várias dúvidas e tornar esse primeiro encontro possível.

Comentários de qualquer tipo são bem-vindos. Até o próximo Dojo!

José Filipe

Bom, antes de qualquer coisa vamos deixar algo claro: provavelmente você não devesse estar dependendo de um banco de dados. Se você estiver testando sua camada de domínio, o ideal é que suas suas classes de controle consumam uma interface de suas classes DAO cuja dependência tenha sido injetada. Isto permitirá que você construa stubs de suas classes de acesso a dados, garantindo que seus testes rodarão rapidamente (e que você sempre tenha coragem para rodá-los!) e não dependam de um banco de dados para serem rodados.

Mas suponhamos que você tenha uma razão muito forte para querer depender de um banco de dados. Você pode estar testando a camada de acesso a dados em si, stressar seu database através de testes unitários ou simplesmente já possuir um conjunto muito grande de testes prontos que desencorajam o refactor (não é algo que você deva se orgulhar, mas coisas assim acontecem). Em qualquer um desses casos, você tem algumas opções:

1. Escrever seus testes para que eles sejam auto-suficientes: uma boa prática, seguindo a “metodologia” AAA de testes unitários: Arrange, Act, Assert. Para alguns casos (com muitos registros envolvidos), entretanto, isto pode ser bastante trabalhoso (e demorado);
2. Criar um backup da base que você roda os testes e restaurá-lo constantemente: menos trabalhoso, mas longe do ideal. Mesmo automatizando o restore via código trabalho adicional associado sempre que os dados fossem efetivamente alterados (para adição de novos testes, por exemplo);
3. Recarregar os dados do database a partir de XML, DBF ou algo que o valha: uma opção legal e até bem difundida. Arquivos XML ou de qualquer outro tipo, entretanto, não são minha representação ideal de dados relacionais;
4. E por último, é claro, a opção que falaremos aqui: utilizar o XtUnit, framework desenvolvido pelo Roy Osherove (uma espécie de bam-bam-bam dos testes unitários) que permite um rollback nos seus dados com um simples attribute de [DataRollBack].

Utilizar o NUnitX é muito fácil. Para utilizá-lo, você só precisa de um teste unitário que faça acesso aos dados e dos passos a seguir:

1. Baixe o assembly da página do próprio Roy (ou o código se você quiser entender como funciona) e adicione uma referência ao seu projeto de testes;
2. Adicione um using para o namespace do framework, pra facilitar a utilização dos attributes:

   10 using TeamAgile.ApplicationBlocks.Interception.UnitTestExtensions;

3. Herde sua classe de testes de ExtensibleFixture:

   14 [TestFixture]

   15 public class NullableTests : ExtensibleFixture

4. Coloque o attribute de DataRollBack em um de seus métodos que fazem acesso a dados:

   71 [Test]

   72 [DataRollBack]

   73 public void PersistNullablePersonWithNullValue()

   74 {

   75 // acesso a dados e tudo mais

   76 }

E pronto! Basta rodar seus testes e ver que seus dados permanecem inalterados mesmo após todos aqueles INSERTs, UPDATEs e DELETEs. Mas como isso acontece? Por trás dos panos o XtUnit utiliza técnicas de orientação a aspectos pra interceptar o início e o fim de cada método de teste, criando uma transação distribuída (garanta que seu MSDTC esteja ativado e corretamente configurado!) e fazendo o rollback no final. Como a transação é distribuída, mesmo que você envolva diferentes bancos de dados tudo vai ser desfeito no final do teste.

É claro que tanto poder traz alguns efeitos colaterais. Diria que “leve” não é a palavra mais apropriada para definir a maneira como a inalteração dos dados é controlada. Mas a praticidade certamente compensa para um conjunto limitado de testes. Por isso, use com moderação!

Abraços e até a próxima!

José Filipe

Já não desenvolvo mais em Delphi há algum tempo e provavelmente hoje exista algo mais simples pra criar arquivos Excel a partir de DataSets ou algo que o valha na linguagem (talvez até já existisse aquela época e eu que não conhecesse), mas a questão é que a demanda permanece e, mesmo no mundo .NET, as soluções utilizadas, em sua maioria, não são exatamente simples. Com esse post pretendo mostrar como criar arquivos Excel a partir de DataSets com ASP.NET de uma maneira bastante simples e direta.

Antes de por a mão na massa vamos entender o conceito da solução. Primeiro fato: DataSets podem ser tratados como arquivos XML. É claro que um DataSet extrapola em muito o simples conceito de um agrupado de propriedades tipadas, mas o fato é que eles podem ser serializados e desserializados para e de arquivos XML, e isto é o que nos importa para esta solução. Um DataSet serializado, sem suas informações de XSD, fica mais ou menos assim:

Segundo fato: um arquivo Excel também pode ser gravado como XML. Desde a versão 2003 do Excel é possível gravar um arquivo Excel como um arquivo XML. A estrutura do arquivo gerado fica assim:

Existem uma séries de outras tags que podem fazer parte do arquivo, responsáveis por formatação, planilhas que estão abertas, maximizadas, etc, etc. Para ver um arquivo completo, basta criar uma planilha, preencher com alguns dados/formatações e Salvar Como..

Voltando à solução: se tanto o DataSet quanto o arquivo Excel são arquivos XML, será que não seria possível transformar um no outro? Considerando sua estrutura hierárquica bastante semelhante (tabelas/planilhas, linhas e células), esta parece ser a melhor solução. Mas existe algo que auxilie nesse sentido? A resposta é sim, e esse algo chama-se XSL.

O termo XSL vem de Extensible Stylesheet Language, e trata-se de uma linguagem que permite transformar um XML original em um formato qualquer. Como assim? De maneira resumida, o XSL permite a definição de tags que possuam uma lógica de filtro/iteração/reconhecimento para que para todo nodo de um XML seja gerado um novo texto, baseado num template. Em nosso caso isso implica, por exemplo, em dizer que todo elemento que esteja no segundo nível (MeuDT, MeuDT2) será uma nova planilha, cada nodo seguinte transforma-se em uma coluna e seus valores vão preenchendo as linhas. Pode parecer confuso, mas um XSL de exemplo ajuda a materializar:

Nesse pequeno trecho do XSL é realizado um foreach em todos os nodos do segundo nível e, para aqueles com nome diferente do anterior (para que ele não crie 1 planilha para cada linha do DataSet) é gerado um novo elemento WorkSheet com nome igual ao do nodo do primeiro nível (por causa do template match=”/*” logo acima). Pode parecer bastante confuso num primeiro momento, mas com alguns testes básicos tudo começa a fazer sentido. Você pode aprender mais sobre transformações XSL nesse link.

Para realizar a transformação completa de um DataSet em um Excel você vai precisar de um XSD bem mais completo que o exemplificado acima, mas não se preocupe, no final do artigo existe um link para um projeto que criei onde você consegue um 100%. Na verdade o que fiz foi pegar o arquivo utilizado nesse blog e realizar algumas modificações para que ele consiga gerar mais de um DataTable num mesmo DataSet (essa era uma limitação explicitada pelo próprio autor).

Criado o XSL, fica faltando somente o código da aplicação ASP.NET. O trecho de código é realmente simples e fica como esse abaixo:

Por questões de exemplificação o código está o mais simples possível. Como vocês podem perceber meu XSL ficou como um arquivo de recurso do projeto, pra facilitar a leitura. A performance da transformação é realmente surpreendente e muito superior a qualquer interação com objetos COM que você possa ter no seu projeto. Comprovado por experiência própria e por outros depoimentos que li sobre isso durante uma discussão semelhante que tivemos na lista do DotNetFloripa.

O resultado é um arquivo Excel gerado com uma planilha por datatable e o título das colunas impresso, como mostrado pelo print abaixo. Para customizar (adicionar formatação, tirar o título, etc) basta que você salve um arquivo Excel, entenda a estrutura gerada por ele e replique com as informações necessárias no seu XSL. Acreditem, não é tarefa das mais complexas.

Com uma estrutura razoavelmente organizada você consegue criar exportações diferenciadas de acordo com sua demanda sem precisar criar novas classes que interajam com objetos COM nem realizar novos deploys de seu software para isto. Um típico caso de desenvolvedor e clientes felizes, o quê mais querer?

Para os interessados em reaproveitar o XSL, ou simplesmente ver um exemplo rodando, coloquei um website no RapidShare, como habitual. É só clicar aqui para baixar.

Abraços e até a próxima!

José Filipe

Faz um tempo que não escrevo (sempre o mesmo papinho), mas baterei o incrível recorde de 2 posts técnicos num mesmo mês com esta postagem, então minha motivação está lá em cima! Na verdade, este post servirá como guia para algumas coisas do trabalho, e isso acaba sendo um “motivador” e tanto..

Apesar de ser a primeira vez que o tema será abordado aqui, acredito que todos que lêem o blog (ou mesmo os que aterrisam aqui esporadicamente) já tenham utilizado ou pelo menos ouvido falar do NHibernate. O NHibernate é um framework de mapeamento objeto relacional para .NET, portado do excelente Hibernate (Java), que facilita sua vida em gravar e recuperar objetos do banco de dados. Acaba ajudando também a manter uma OO mínima, já que sem isso o trabalho fica muito mais doloroso, o que também é muito positivo.. O NH permite mapear diversos tipos de colunas, trabalhar com chaves geradas automaticamente e mais uma infinidade de coisas que nem uma centena de posts conseguiriam cobrir.

O fato é que, nesta semana, caímos num problema com campos que possuem valores default. Contextualizando: possuímos uma grande aplicação que foi desenvolvida originalmente em .NET 1.1 e hoje encontra-se e .NET 2.0. Na época do 1.1, tipos “nullables” não passavam de um sonho e as pessoas arrumavam soluções criativas para contornar a questão: criando structs próprios, utilizando valores default, etc. As soluções não eram exatamente o sonho de nenhum desenvolvedor, mas, dada as restrições do framework, funcionavam bem desde que fosse mantida certa disciplina. Neste projeto a solução utilizada foi a de valores default. Alguns campos são inicializados com extremos de seu tipo (ex.: Int32.MinValue) enquanto outros assumem valores “mágicos” (ex.: -1, 03/03/0003). No momento da persistência, estes valores são tratados pela camada apropriada (aquela mesma citada por problemas de performance em outro post) e transformados em DbNull (ou vice-versa).

Tudo funcionava bem e ninguém pensava em refatorar este comportamento nesse exato momento, até que tivemos que construir uma segunda implementação da camada DAO para armazenamento de um banco de dados local. Como o banco local não poderia ser SQL Server (ao qual nossa DAL está bastante amarrada), a opção de persistência foi o NHibernate. Mapeamos as entidades e, depois de alguns refactors no código para deixá-lo mais “OO”, as coisas pareciam funcionar bem. Isto, é claro, até o momento que foi percebido que as colunas que antes eram salvas como null e recuperadas como valores default não estavam mais comportando-se dessa maneira, o que acabava deixando a lógica de negócio inconsistente em alguns pontos. Neste momento, tínhamos duas opções:

1. Partir pra tipos Nullable. Isto consistiria em: a) alterar todas as entidades e a camada de persistência para trabalharem com tipos nullable, b) alterar as classes de negócio para não esperarem os valores, c) torcer pra não ter esquecido nada e não ter quebrado nenhuma lógica do sistema com isso (não temos testes unitários cobrindo o código);
2. Encontrar uma maneira de fazer o NHibernate entender que alguns valores deveriam ser mapeados como nulo sem ter que escrever muito código pra isso.

Pela minha “imparcial” exposição das opções vocês devem concluir que optamos pelo segundo caminho. Pode parecer gambiarra à primeira vista, mas garanto que foi uma decisão baseada numa boa dose de pragmatismo: garantia de testes, falta de recursos e prazos apertados não são coisas muito fáceis de serem conciliadas num projeto realmente grande e complexo.

Feita a decisão, partiu-se para a pesquisa. Alguém da equipe citou a possibilidade de UserTypes. Já havia ouvido falar de UserTypes no NHibernate mas nunca havia olhado para uma implementação, muito menos criado um na prática. Depois de uma procura rápida, fiquei mais tranqüilo com os exemplos que encontrei: bastaria implementar uma interface (IUserType) cujos vários métodos já estavam implementados com um dos sites encontrados e modificar somente 2 métodos. Moleza! O problema é que os benditos UserTypes, que já tinham até sido prototipados para o sistema, exigiriam a criação de uma classe para cada tipo e valor default. Assim, teríamos que ter uma classe para inteiros com valor default -1, shorts com valor default -32768, outra para shorts com valor default -1, e assim por diante. Nada prático! Os desenvolvedores teriam que criar uma nova classe toda vez que descobrissem um novo tipo com valor default.

Com o problema de precisar criar uma dezena de classes para um problema tão simples, voltei pro Google. Dessa vez a pesquisa rendeu uma segunda interface que, quando implementada, permite setar parâmetros definidos via mapeamento que são passados para a classe. Voila! Com um UserType parametrizável, basta passarmos o tipo .NET que queremos mapear, qual tipo do banco de dados que ele corresponde (um Enum do próprio NH) e dizer o valor default que deve ser comparado para termos uma solução genérica, elegante e simples para toda a equipe de desenvolvimento: eles só precisarão alterar os arquivos de mapeamento minimamente para informar o valor default de cada campo.

Para mostrar como implementar o conceito, montei um exemplo com duas classes Person: NullablePerson e RegularPerson. A idéia com as duas classes é poder comparar exatamente o comportamente dos tipos nullable com a solução que utilizaremos. Isto também facilita um pouco a criação dos testes unitários. O código das classes é ridiculamente simples e ficou assim:

Percebam que a única diferença entre as classes é a utilização do símbolo ? depois dos tipos, que equivale à utilização de Nullable<>. A tabela do banco de dados que armazenará estas entidades (mesma tabela para ambas entidades) é igualmente simples:

CREATE TABLE [dbo].[PERSON](
 [ID] [int] IDENTITY(1,1) PRIMARY KEY,
 [NAME] [varchar](100) NULL,
 [AGE] [smallint] NULL,
 [DT_REGISTER] [datetime] NULL
)

Feito isto, basta o mapeamento do NHibernate para que as entidades possam ser salvas no banco de dados:

Notem que este é o arquivo de mapeamento da classe NullablePerson. Com ela possui propriedades nullable, só com isto já funciona maravilhosamente bem. Para nossa classe RegularPerson, entretanto, precisamos criar uma estrutura que permita que valores default sejam transformados em null e vice-versa. Para isto, vamos criar uma classe chamada NullDefaultValueType, que implementará duas interfaces: IUserType e IParameterizedType. A primeira é responsável por permitir que nossa classe possa ser mapeada no arquivo do NHibernate como um tipo de qualquer coluna. A segunda, por sua vez, permite que parâmetros sejam mapeados no arquivo de configuração para serem passados para esta classe. Apesar da descrição parecer complexa, a solução é bastante lógica e linear, acompanhe na sequência.

Abaixo segue a declaração da classe com as implementações relevantes da interface IUserType. Os demais métodos foram omitidos por não adiconarem comportamento relevante ao nosso caso.

O que precisa ser notado neste trecho de código são as propriedades, que posteriormente serão inicializadas pela implementação da outra interface, e os dois métodos: o que retorna o valor para o NHibernate (NullSafeGet) verifica se o valor do banco de dados é nulo e, se este for o caso, retorna o valor default configurado no lugar. O método de set (NullSafeSet), por sua vez, faz o contrário: verifica se o valor recebido foi o valor default e salva como nulo no banco de dados. Isto permitiria, por exemplo, que objetos NullablePerson e RegularPerson interagissem com o mesmo objeto sem problema de compatibilidade: o que para um é nulo, para o outro é valor default, de maneira transparente e independente do banco de dados.

A implementação da segunda interface (IParameterizedType) é mais simples: basta implementarmos um métodos que receberá os parâmetros e setar nossas propriedades. Ficou assim:

Vejam que a recuperação dos parâmetros é bastante simples. No método estamos pegando os 3 parâmetros necessários para nossa classe funcionar corretamente e setando em propriedades privadas de nosso UserType. Depois disto, basta alterar o mapeamento das propriedades de RegularPerson para algo assim:

Apesar do mapeamento de NullablePerson permanecer exatamente o mesmo, vemos que as propriedades que requerem o tratamento de valores default ganharam alguns nodos a mais. Apesar deste pequeno acréscimo, o mapeamento para o restante da equipe foi facilitado ao máximo com apenas uma nova classe, totalmente parametrizável. Além disso, instâncias de NullablePerson e RegularPerson podem ser utilizadas em paralelo, sem problema. Isto é comprovado pelo teste unitário abaixo:

E é isso! Com este post vimos como os UserTypes no NHibernate podem nos ajudar a contornar situações aparentemente não suportadas pela ferramenta, além de poderem ser parametrizados pelos próprios arquivos de mapeamento. Para quem quiser o código completo junto com o conjunto de testes unitários, coloquei os projetos no RapidShare, basta clicar aqui para baixar.

Um abraço, bons códigos e até a próxima!

Filipe

As coisas têm estado bastante corridas nas últimas semanas, motivo pelo qual terminei o mês de abril com o impressionante número de 1 post. Mas em maio o objetivo é mudar isso: no mínimo 2, ..

Nas últimas semanas tenho lido bastante sobre testes unitários, inversão de controle (e injeção de dependência), princípios SOLID e algumas outras práticas defendidas pela comunidade ALT.NET.

Apesar de testes unitários já serem tópico de atenção há muito tempo e eu ter uma clara noção de como eles funcionavam, tenho que admitir que nunca os havia utilizado na prática. Como um post do Karl Seguin, via CodeBetter, nesta semana falou do assunto também e alguns projetos na empresa seriam bastante beneficiados, pensei: é hora de dar uma pesquisada e de quebra tirar a poeira do blog!

Pra demonstrar um projeto com testes unitários básicos eu vou utilizar o NUnit. O VS2008, na edição Team System, também pode fazer testes unitários, mas minha escolha baseia-se no fato de eu não apoiar o recorrente comportamento “anti open frameworks” da MS. Além do custo do VS ser absurdo, eu realmente gostaria de poder participar de uma comunidade cada vez mais ativa sem depender da MS pra tudo. Nesse quesito é indiscutível a superioridade do Java (na verdade de sua comunidade) sobre o .NET, e pra mim grande parte desta culpa pertence à MS..

Antes de tudo, você precisa baixar os assemblies do NUnit. Pra mostrar as funcionalidades básicas do NUnit vamos criar uma solução no VS com dois projetos: uma class library para as classes do projeto e outra com nossas classes de teste. Você até pode deixar seus testes no mesmo assembly de suas classes controladoras ou de domínio, mas isto adiciona uma dependência de sua aplicação ao assembly do NUnit na hora do deploy que não é legal.

Vamos criar um exemplo clássico: uma classe calculadora. Pra simplificar as coisas por aqui, vou criar só um método: Somar. Para os demais métodos seria simplemente repetir o processo. A interface de sua classe ficaria mais ou menos assim:

Você pode perceber que ambos o métodos não está retornando o cálculo correto, e isto foi intencional: a idéia é que os testes primeiro falhem pra depois corrigirmos os códigos das classes, bem TDD mesmo. Pode parecer estranho num primeiro momento mas isto garante que você desenvolva código baseado em testes que você sabe que eles tem que passar, o que acaba garantindo a qualidade do seu código (imaginando que você não fique com preguiça de escrever todos os testes, é claro).

Depois da interface da classe definida, vamos escrever nossa classe de testes. Basta criar uma classe normal na class library de testes, adicionar a referência ao assembly do NUnit e criar um método TestarSoma(). Todos os métodos de teste não devem ter parâmetros nem retornar nada (void). Isto vai permitir ao NUnit executar os testes de maneira atômica, ou seja: tudo que um teste precisa para rodar é seu próprio código. Nosso método de teste ficaria mais ou menos assim:

Os pontos de interesse nesse trecho de código são:

1. O attribute [Test] no topo do método: esse attribute é o que diz ao NUnit que trata-se de um teste unitário que deve ser executado. Existem outras tags que o NUnit disponibiliza, permitindo informar que uma exceção é esperada, que o método ainda não está implementado, extensões para dar Rollback automático no seu BD, etc, etc. O [Test] é o básico;
2. A classe Assert: essa é uma classe que fica no namespace do NUnit (NUnit.Framework) que é responsável por dizer se o teste funcionou ou não: ela fornece métodos estáticos para comparar igualdade, diferença e uma série de outras possibilidades.

Antes de rodar nosso projeto com o NUnit só precisamos de mais um passo: adicionar o attribute [TestFixture] à classe de testes. Isto indica ao NUnit que esta classe possui métodos de testes. A definição de sua classe ficará assim:

Feito isto é hora de rodar nosso teste pela primeira vez. Abra o NUnit GUI na pasta de instalação ou através do menu iniciar, e através do menu File > Open Project indique a .DLL de seu projeto de testes. O NUnit identificará suas classes e métodos de teste automaticamente. Clique no botão Run e seu resultado deverá ser semelhante ao print abaixo:

Pelo NUnit GUI é possível perceber que nosso único teste implementado até o momento – TestarSoma – falhou. Pelos detalhes exibidos na parte direita da tela existe um detalhamento dizendo que o valor esperado era 5, mas foi retornado 0: o que já esperávamos, pois nosso método ainda não está implementado.

O próximo passo, então, é implementar o método da classe Calc para que nosso teste passe. Para isto, vamos alterar o método Soma para retornar o óbvio:

Com o método implementado, basta compilar a solução e ir novamente ao NUnit GUI (que já atualiza o assembly automaticamente). Rodando novamente o teste, percebemos pela cor verde que o teste rodou com sucesso:

E é isso! Com isto você já tem uma noção básica de como utilizar o NUnit para construir seus testes unitários. Existem uma série de outros attributes que podem facilitar, em muito, sua vida, mas isto é assunto para um próximo post.

Use e abuse de testes unitários com o NUnit e, no caso de dúvidas ou sugestões de temas que você gostaria de ver por aqui é só entrar em contato!

Abraços, bons testes e até o próximo post!

Filipe

Performance de aplicações sempre foi e continuará sendo causa de muita discussão – e invariavelmente de muitos problemas também.

Até pouco tempo atrás, pensar em profile de código era tido quase que como inviável, dada a complexidade e quantidade de recursos exigidas por este tipo de ferramenta.

O Visual Studio 2008 trouxe um recurso de profile de código muito interessante, possibilitando em poucos cliques é possível descobrir os pontos de seu código que estão consumindo mais recursos e otimizá-los.

Como o conjunto de recursos é razoável, demoraria um bocado pra escrever um post completo, então resolvi criar um vídeo com os principais pontos. Já aproveito e testo a aceitação do recurso por aqui.

O código fonte da aplicação de teste, para os que quiserem reproduzir, pode ser baixado aqui.

Para os que quiserem entender um pouco melhor, saiu na MSDN Magazine de março um artigo sobre o tema (fonte de inspiração pra esse aqui ).

Comentários e dúvidas sobre o assunto são incentivados, bem como a opinião sobre a utilização do vídeo no lugar do texto escrito.

Abraços e até a próxima!

Zé Filipe

Tudo corria bem até que um de nossos produtos começou a ganhar uma escala até então inédita para nós num único servidor, e a criação das classes de acesso a dados começou a ficar bastante lenta. Fuça daqui, revira de lá, chegou-se à conclusão que a serialização do bendito arquivo XML estava consumindo processamento demais. Como não suspeitamos do .NET Framework 1.1 (sim, ainda estávamos nele no ano passado), acabamos criando uma Factory que centralizava numa coleção estática todas coleções desserializadas pela aplicação, realizando o controle da modificação do arquivo através da classe FileSystemWatcher (System.IO). A performance melhorou e tudo parecia estar mais uma vez sob controle..

Como nada dura para sempre, entretanto, aconteceu desta mesma camada de acesso a dados ter problemas com concorrência. Coincidentemente, no meio dessa análise de concorrência, ocorreu também de eu receber um link para o recurso de profiling de código do VSTS (assunto para um próximo post) e, adivinhem, não é que a leitura do XML continuava consumindo tempo demais?

Tudo bem que a performance dificilmente estaria ligada aos problemas de concorrência, mas era preciso entender o porquê daquilo. Procedimento padrão: Google -> XmlSerializer performance e… batata! Caí num artigo sobre um problema de performance com o XmSerializer e seus workarounds para os frameworks 1.1 e 2.0+. O que acontece, em resumo, é o seguinte:

• Ao criar uma instância da classe XmlSerializer com os construtores XmlSerializer(type) ou XmlSerializer(type, string), o .NET Framework cria automaticamente o serializador e desserializador daquele tipo, criando um assembly para armazená-lo (sim, isso mesmo, um assembly é criado em tempo de execução)..

• No .NET Framework 1.1, isto era feito à cada chamada do construtor, independente se aquele tipo já foi criado ou não! Incrível, não? Alguém se habilita pra chutar por que tínhamos problemas de performance? Existe um workaround no artigo que linkei acima para este caso, mas não testei por não ser o foco;

• Já no .NET Framework 2.0+, isto é feito assim que a classe é criada e o assembly é reutilizado no caso de reincidência de construção daquele tipo. Bem melhor, mas longe do ideal para sistemas em que a performance é crítica..

A grande melhoria de performance vem com o fato de que é possível, através de um utilitário de linha de comando chamado sGen.exe (acessível pelo VS promt) criar uma pré-compilação de todos esses tipos que vão ser serializados. É possível compilar todos os tipos de uma DLL ou somente alguns (sgen MeuAssembly.dll, para todos, por exemplo). Também é possível, nas opções de Build do projeto no próprio VS habilitar uma opção chamada Generate Serialization Assembly, que vai fazer exatamente o mesmo trabalho. Em ambos os casos, é gerado na pasta de build um arquivo com o nome MeuAssembly.XmlSerializers.dll, que quando jogado na sua pasta \bin reduz, e muito, o tempo de criação da classe XmlSerializer.

É isso! Esta pode não ser uma situação das mais corriqueiras mas que pode destruir a performance de sua aplicação, então é sembre bom ficar atento!

Abraços!

Zé Filipe

O objetivo desse espaço é servir como um diário de bordo das andanças, tombos e lições aprendidas no dia-a-dia de tecnologia, principalmente .NET. Melhor assim, já que mesmo que ninguém visite o blog sei que vou poder salvar algum tempo de Google nas tão comuns situações de “eu já vi isso. como se fazia mesmo?“.

O nome do blog, certamente familiar pra alguns (aquelas aulas de criatividade não serviram pra nada mesmo), refere-se à funcionalidade de debug existente em IDEs pra acompanhar o valor de uma variável ao longo da execução. Mais uma tentativa pra ver se alguém assina o RSS Feed esperando encontrar coisas interessantes..

Agora que o gelo está quebrado, vem o primeiro post “as vera”! E, é claro, pra não fugir das frases prontas: sugestões, críticas e elogios são sempre muito bem-vindos..

Abraços!

Zé Filipe