Teste unitário de código legado – Microsoft Moles (e Pex)

Não é raro acontecer de você precisar criar teste unitário para um dado código legado que, por qualquer motivo, não possui suporte para utilização de desvios (ex: IoC/DI). Nestes casos, ou opta-se por não escrever o teste, ou escreve-se um teste de integração / blackbox englobando rotinas periféricas que aquele fragmento sendo testado faz uso ou, o código legado é alterado para permitir o registro de desvios para teste.

Não acredito que qualquer uma das opções acima seja algo confortável, e acho que a grande maioria das pessoas deve concordar com isto.

Tenha em mente que: Códigos não testados vivem dentro da caixa de Schrödinger. Eles podem estar funcionando ou não. Você só vai ter certeza quando alguém passar a usá-lo.

Mas calma! Este problema não tende mais a afligir programadores .Net. Já faz algum tempo, a Microsoft liberou um casal de ferramentas que visa facilitar a vida do desenvolvedor de testes. Estas ferramentas são as seguintes:

• Pex: Framework de whitebox testing que permite, de forma automatizada, encontrar fragilidades e problemas em seu código. Possui um grande foco em prover um alto nível de cobertura de código.
• Moles: Framework, baseado em delegades, para criação de desvios e stubs para plataforma .Net.

Este artigo visa cobrir apenas a utilização de Moles, porém eu gostaria de frisar que o Pex é uma ferramenta tão interessante quanto e vale muito a pena dar uma olhada que seja.*

Extension Methods e interfaces

Com certeza não colocaria a implementação de uma rotina de comparação de propriedades entre duas instâncias distintas de um dado objeto (que possam retornar um dicionário contento apenas o que existe de diferente entre elas) como sendo algo complexo, na verdade existem diversas maneiras de implementar esta solução. A título ilustrativo poderíamos elencar algumas idéias como, por exemplo escrever um de/para manual diretamente nos objetos², o uso de reflection para varrer as propriedades de escopo público de qualquer objeto da aplicação, ou até mesmo se formos pensar completamente out of the box, trabalhar com o compare entre as strings XML serializadas dos objetos em questão.

Mas vamos adicionar ao requisito principal ( comparar objetos) um outro requisito que diz respeito a impossibilidade de alterarmos a implementação atual dos objetos em questão (ex: estes objetos estão ‘trancados’ em um assembly que não temos acesso / não são de nossa responsabilidade) e, existe também a necessidade de obtermos o máximo de performance desta rotina. Um detalhe importante relativo ao lado da performance é que, eventualmente, poderemos trabalhar com objetos muito grandes e complexos (propriedades com lista / dicionários de outros tipos do sistema) que mudam com o tempo sem que todos os envolvidos no projeto sejam notificados. Agora ficou divertido!

Pra que toda a solução proposta aqui no post fique bem clara (e ninguém queira me queimar sob acusação de magia negra), vamos começar bem do começo.

Anonymous type para todos!

É, como previsto, demorou um tempo entre meu último post e este. Neste post, abordarei uma situação que aconteceu comigo hoje e achei por bem compartilhar o caso e o desfecho. Fato é que acho que encontrei uma forma de passar Anonymous Types por parâmetros e consumi-los futuramente sem precisar fazer a gambiarra sugerida no MSDN. Calma que eu explico…

Lista para leitura – Microsoft Research

Na tentativa de manter posts fresquinhos por aqui, segue uma pequena lista dos tópicos, textos e ferramentas que mais me chamaram a atenção nos últimos dias (todos parte da Microsoft Research):

• Kodu (parece bem divertido!)
• RADAR (tem que abrir no IE)
• Rex (pra quem não acha que expressão regular é coisa do diabo)
• Ripley (bem interessante pra quem usa AJAX to the core)
• RobusHeap (tipica coisa que você olha e imagina: PQ nunca pensei nisto?)
• Spectator (tem alguns sites grandes precisando conhecer esta ferramenta! lol)
• Automated Annotation of Human Faces in Family Albums (paper)

e, meu predileto: Infer.Net

Escopo no window.setTimeout

Sim, mais um micropost. Agora para falar de um detalhe relacionado a esta função do JavaScript que vez ou outra causa uma dor de cabeça na hora de usar.

O problema

Imagine que você tem o seguinte código:

var MeuObjeto = function () {
            var _intervalo = 1000;
            this.Rodar = function () {
                alert("rodou!");
                window.setTimeout(function () { this.Rodar() }, _intervalo);
            }
        }

Ao que parece, tudo certo, certo? Errado!

DIY – Faça sua parte!

Quem me conhece sabe que por questões de criação (graças a Dna. Mãe! :D) eu to sempre tentando me envolver em projetos que visam difundir o conhecimento que acumulei durante os anos que trabalho na área. Faz coisa de dois anos dei o primeiro passo neste sentido (que infelizmente não foi muito feliz) e, agora estou tentando uma nova empreitada.

(To.Double() || !To.double()) { return “That’s the question”; }

Aconteceu hoje de um cliente me questionar sobre a existência de um eventual overhead gerado por boxing e unboxing de variáveis do tipo Double (big D) contra a utilização de double (small d). Após explicar a ele que isto não existe pois ambas as variáveis são armazenadas no stack, notei que havia ficado aquela pitada de desconfiança e, para fechar o assunto de forma adequada, preparei um pequeno exemplo, segue:

DSL usando M

Como todas as outras coisas da minha lista de “TODOs”, a linguagem M é uma das que mais tinha destaque e finalmente consegui um tempo para enfrentar o processo de aprendizado a fim de tirar o melhor proveito do que ela se propõe a resolver.

Conceitualmente, a linguagem M se baseia em quatro pilares: Linguagem, dados, constraints e transformação. Vamos a eles.

Quick Update: Layer Validation

Eu sempre me perguntei: Quando será que farão (Microsoft) uma ferramenta que possa ser usada pra impedir que aquele programador preguiçoso atrapalhe todo o planejamento arquitetural do projeto. A resposta aparentemente chegou em forma de uma Feature do VS2010.

O tempo passa, o tempo voa, mas o EntityFramework continua estranho!

Não rima, mas é verdade.

Faz mais de um ano eu escrevi um post em meu outro blog (agora migrado pra cá) sobre minhas primeiras impressões quanto a ferramenta de dados lançada junto ao .Net framework 3.5 (SP1),  conhecida popularmente como Entity Framework e, para minha surpresa, o motivo que me fez não usar a solução em NADA no passado deve ser a mesma que me prevenirá de usá-la na versão atual.