Existe um grande equívoco pairando no mercado a respeito de Arquitetura de Software e o Papel do Arquiteto de Software em uma equipe de desenvolvimento.

Alguns destes equívocos são baseados no mal-entendimento de alguns conceitos, outros baseados em mal-conceitos (ou má-padronização) de alguns entendimentos (se é que é certo falar assim). Mesmo entre os grandes arquitetos da comunidade, existem algumas divergências de opiniões sobre a definição da arquitetura e do papel do arquiteto, mas é certo dizer que, no geral, existe um consenso a respeito do essencial.

O Application Architecture Guide da Microsoft faz uma enumeração das definições mais coerentes e tenta relacioná-las.

O trecho a seguir é tradução do livro.

O que é Arquitetura de Software?

Arquitetura de Software é frequentemente definida como a estrutura ou estruturas de um sistema. Diversos experts conhecidos da indústria tem expandido esta definição com as informações baseadas nas decisões que precisam ser tomadas relacionadas à arquitetura. Aqui nós vemos um pouco de algumas definições formais de arquitetura, e então teremos uma visão mais informal.

Arquitetura segundo Kruchten, Booch, Bittner e Reitman

Philippe Kruchten, Grady Booch, Kurt Bittner e Rich Reitman derivaram e redefiniram a definição de arquitetura baseada na obra de Mary Shaw e David Garlan (Shaw and Garlan 1996). A definição deles é:

Arquitetura de Software engloba todas as decisões significantes sobre a organização de um sistema de software, inclusive:

• Escolha dos elementos estruturais e suas interfaces pelos quais o sistema será formado.
• Comportamento como especificado na colaboração entre estes elementos.
• Composição dos elementos estruturias e comportamentais em subsistemas maiores.
• Estilo arquitetônico que orienta esta organização.

Arquitetura de software também envolve  questões de funcionalidade, usabilidade, resiliência (escalabilidade), performance, reusabilidade, compreensividade, constraints tecnológicas e econômicas (esta nós conhecemos bem), trade-offs (problemas causados pela resolução de outros problemas) e estética.

Arquitetura segundo Fowler

Em seu livro, Patterns of Enterprise Application Architecture (Padrões de Arquitetura para Aplicações Empresariais), Martin Fowler destaca alguns temas comumente recorrentes quando explica arquitetura:

•  
  • O mais alto nível de quebra do sistema em suas partes.
  • As decisões que são difíceis de mudar.
  • Existem muitas arquiteturas em um sistema.
  • O que for arquitetonicamente significante pode mudar durante o tempo de vida de um sistema
  • No fim, arquitetura se resume ao que quer que seja importante.

Arquitetura segundo Bass, Clements e Kazman

Em Software Architecture in Practice (Arquitetura de Software na Prática) – Segunda Edição, Bass, Clements e Kazman definem arquitetura da seguinte forma:

A arquitetura de um software de um programa ou sistema computacional é a estrutura ou estruturas de um sistema, que inclui os elementos de software, as propriedades externamente visíveis destes elementos, e os relacionamentos entre eles. Arquitetura é responsável pelas interfaces públicas dos elementos. Seus detalhes privados (detalhes que tenham a ver somente com a implementação interna) não fazem parte da arquitetura.

Por que precisamos de Arquitetura?

Como em qualquer outra estrutura complexa, o software precisa ser construído sobre uma fundação sólida. Falhar em considerar cenários-chave, falhar no design de prolemas comuns ou falhar na consideração das consequências em longo-prazo de decisões-chave pode colcoar toda a aplicação em risco. Ferramentas e plataformas modernas ajudam a simplificar as tarefas de construção de aplicações, mas elas não substituem a necessidade do haver um design da sua aplicação baseado nos seus cenários específicos. Os riscos expostos por uma arquitetura pobre podem levar a um software instável, incapaz de suportar requisições de negócio, ou poderiam ainda impedir a aplicação de funcionar quando publicada no ambiente de produção.

Considere as seguintes questões de auto-nível quando estiver pensando sobre a arquitetura de software:

• Como a aplicação será publicada em produção?
• Como os usuários usarão a aplicação?
• Quais são os atributos de qualidade exigidos, tais como segurança, performance, concorrência, internacionalização e configuração?
• Quais são as tendências arquitetonicas que podem impactar na sua aplicação agora ou depois dela ser publicada?

Arquitetura x Design

De acordo com Martin Fowler em “Quem precisa de um arquiteto?”:

…Os desenvolvedores que estão trabalhando em um projeto tem um entendimento compartilhado do design do sistema. Este entendimento compartilhado é chamado de “Arquitetura”. Este entendimento inclui como o sistema é dividido em componentes e como os componentes interagem através de interfaces. Estes componentes são normalmente compostos de componentes menores, mas a arquitetura inclui somente os componentes e interfaces que são entendidos por todos os desenvolvedores.

Portanto, a arquitetura foca em como os componentes e as interfaces são usadas ou interagem com outros componentes. Escolher estruturas de dados ou algoritmos a serem implementados dentro do componente não é uma questão de arquitetura. Invés de usar regras rápidas e difíceis para distinguir arquitetura de design, faz mais sentido combinar estas duas áreas. Em alguns casos, as decisões são claramente mais arquitetônicas por natureza. Em outros casos, as decisões são mais sobre o design, e como elas te ajudam a visualizar esta arquitetura.

Objetivos do Usuário, do Negócio e do sistema

Os sistemas deveriam ser arquitetados considerando os objetivos do Usuário, do sistema e do negócio. Para cada uma destas áreas se destacam cenários-chave, atributos de qualidade importantes (por exemplo, manutenabilidade), satisfatores-chave e dissatisfatores-chave. Quando possível, desenvolva e considere medidas que te ajudam a medir o sucesso de cada uma destas áreas.

Figura 1 - Objetivos do Usuário, do Negócio e do Sistema

Trade-offs são semelhantes entre cada área, e um ponto de equilíbrio precisa ser encontrado. Por exemplo, responsividade pode ser o maior objetivo do usuário, mas o admnistrador do sistema não vai investir no hardware exigido para atender a demanda o 100 porcento do tempo de execução. Um ponto de equilíbrio precisa existir para atender o objetivo em somente 80 porcento do tempo.

Os objetivos da Arquitetura

A Arquitetura da aplicação procura construir uma ponte entre os requisitos de negócio e os requisitos técnicos, entendendo os casos de uso, e então encontrando maneiras de implementar estes casos de uso no software. O objetivo da arquitetura é identificar os requisitos que impactam na estrutura da aplicação. Uma boa arquitetura reduz os riscos de negócio com a construção de uma solução técnica. Um bom design é flexível o suficiente para ser capaz de lidar com as mudanças naturais que podem surgir com o passar do tempo em tecnologia de Hardware e Software, bem como em cenários e requisitos de usuário. Um arquiteto deve considerar o impacto global das decisões de design, os trade-offs herdados entre atributos de qualidade (tais como performance e segurança), o os trade-offs necessários para atender requisitos de Usuário, de Negócio e de Sistema.

Tenha em mente que a arquitetura deveria:

• Expôr a estrutura do sistema mas esconder os detalhes de implementação.
• Compreender todos os cenários de Casos de uso.
• Tentar identificar as preocupações de vários stakeholders.
• Lidar com ambos os requisitos: funcionais e de qualidade.

–

Para quem quiser ler mais, o Application Architecture Guide da Microsoft está disponível para Download gratuito no site do Patterns and Practices.

Aqui no blog eu irei postar mais a respeito de Arquitetura de Software e o Papel do Arquiteto.

Até logo.

Mas, antes de continuar, eu me esqueci de instruir o básico a respeito do Rhino.

O Rhino é um framework que pode ser baixado em http://www.ayende.com/projects/rhino-mocks.aspx.

Neste site, você tem, também, toda a documentação disponível.

Até mesmo eu preciso rever o Rhino para descobrir se tem algo dele que deixei de explorar. O fato é que o pouco que sei já me torna capaz de fazer um uso excelente dele. Para usá-lo é simples, basta colocar no seu projeto uma referência a Rhino.Mocks.Dll.

As principais classes do Rhino se encontram no Namespace Rhino.Mocks.

A principal classe que você vai usar é a Rhino.Mocks.MockRepository.

Uma instância de MockRepository irá servir para criar seus Mocks e monitorá-los.

Vamos rever o exemplo do último post:

//setup
var mocks = new Rhino.Mocks.MockRepository();
ICustomerBusiness objBusCustomer =
	mocks.StrictMock<ICustomerBusiness>(null);
ILogger objLogger =
 	mocks.StrictMock<ILogger>(null);

Observe que é da instancia de MockRepository (mocks) que executamos o método StrictMock<T>, que gera para nós o mock baseado baseado no tipo passado.

mocks.Record();
objBusCustomer.InsertCustomer(Customer);
objLogger.WriteLog("Cliente Inserido");

mocks.ReplayAll();
//exercise
Controller.InsertCustomer(Customer);

//verify
mocks.VerifyAll();

O método Record() faz com que o MockRepository (mocks) passe a monitorar tudo o que acontece com os mocks criados. Assim, quando invocamos o método InsertCustomer do mock de ICustomerBusiness, a instância de MockRepository compreende esta chamada e deixa guardada, bem como a chamada ao método WriteLog do mock de ILogger.

Quando invocamos o método ReplayAll(), a instância de MockRepository começa passa a monitorar os mocks esperando que tudo o que aconteceu durante a gravação (Record()) aconteça novamente. A forma como administramos o MockRepository para se comportar de acordo com o que acontece durante o ReplayAll() vai depender do tipo de mocks que criamos. No caso do StrictMock<T>, que foi o que usamos para criar os mocks que estão sendo usados, o MockRepository espera que aconteça exatamente tudo o que aconteceu durante a gravação, nada mais, e nada menos. Se no meio do caminho acontecer algo que ele não tinha gravado, ele lança uma exception.

Quando finalmente chegamos no VerifyAll, a instância de MockRepository verifica se tudo que de fato deveria acontecer, aconteceu. Ou seja, ele garante em que ponto que tudo o que deveria acontecer no ReplayAll() já deveria ter acontecido. Se algum método tiver sido deixado de ser chamado, uma exception será lançada.

O que garante o sucesso dos testes é que o método InsertCustomer do Controller faz exatamente o que orientamos o objeto Mocks a gravar. Ou seja, usamos o Record para definir o comportamento esperado, e então usamos o ReplayAll() para iniciar a verficação de que este comportamento realmente está sendo obedecido pelo objeto que estamos testando.

Se você entrar no método InsertCustomer do Controller e inserir um novo log, ao rodar o teste, ele dará uma falha (vermelho) pois o mocks só gravou uma única chamada ao WriteLog. Se o parâmetro do WriteLog for diferente do que foi gravado, também ocorrerá uma falha.

Desta forma, o código do último post fica mais claro e você pode entender melhor o que está acontecendo aqui.

Mas, como mockar um objeto que possui um método cujo os parâmetros da chamada eu sou incapaz prever? E como entender se um método funciona se o seu bom funcionamento depende do retorno da chamada de um método de um objeto mockado?

Isso tudo está na pauta para o nosso próximo post, que espero ter condições de redigir logo e publicar em breve.

Stay Sharp!

E quando executar todos os testes, precisará verificar se os arquivos de Log foram devidamente criados no disco. Se os e-mails que o sistema deveria enviar foram devidamente enviados. E tantas outras evidências a colher em tantos lugares que não fazem parte do escopo de seus testes.

No fim das contas, tudo o que você precisa saber é se o seu software está se comportando como deveria. E você pode fazer isso executando um select na tabela de customers pra saber se o teste realmente inseriu alguém lá, ou pode simplesmente procurar algum meio de garantir que seu código faz isso sem que isso realmente ocorra.

Conheça o uso de Mocks.

Mocks são objetos criados para fingir que são objetos que serão usados pelo seu teste, afim de fazer com que o objeto que você está testando funcione de forma transparente usando os Mocks no lugar dos objetos que esperaria usar. Ou seja, invés da minha classe de negócio criar uma instancia de uma classe de repositório, ela cria uma instancia de um Mock que se finge de repositório.

Mais do que isso, o Mock não somente se finge de repositório, como ainda monitora todas as interações com ele. Por exemplo, dizemos ao Mock que ele precisa ficar atento para receber o chamado ao método Add, e ele observa se este método é de fato chamado. Se não for chamado, ele lança uma exceção e o teste dá vermelho.

Entenderam?

Não?

Vamos supor que você esteja fazendo um teste no seu controller. Ele tem um método InsertCustomer que recebe um objeto Customer. Você sabe que ele tem que criar uma instancia do objeto de negócio, executar o método Insert do objeto e fazer um log em um arquivo texto.

Ora, acabamos de falar exatamente o que seu controller tem que fazer quando o método InsertCustomer for invocado, não? Então, ao término do teste, precisamos ter um registro inserido no banco de dados e um arquivo de texto com as informações de Log, certo?

Não! Não necessariamente!

Tudo o que você precisa é se preocupar se o controller se comportou como deveria, e para ter certeza de que o comportamento do controller está sendo o esperado, você não é forçado a realmente inserir uma linha no banco de dados e criar um arquivo texto. Você só precisa abstrair este comportamento em objetos separados, criar um mock que simulará estes objetos e monitorar o mock para certificar-se de que o seu controller está se comportando como deve.

No exemplo a seguir usarei o Rhino Mocks, mas, assim como no caso do MsTests, existem diversas ferramentas Mock para serem usadas. Provavelmente escreverei um Post mais tarde para comparar os principais frameworks disponíveis.

É assim que queremos testar nosso controller:

Mas para este teste dar certo, nós teremos que implementar a camada de Negócio, o que significaria iniciar um novo ciclo antes de testar o controller. Se seguirmos este percurso, veremos que teríamos que implementar também a camada de acesso a dados para testar a camada de Negócio para, só então, finalmente, testar o controller. Não é bem isto que queremos com o TDD. Com o TDD queremos começar de cima para baixo. Queremos começar testando o controller para programá-lo, quando ele estiver pronto, testaremos a camada de negócio e a programamos, quando ela estiver pronta, testaremos o controller de novo pra saber se nada afetou seu funcionamento… e assim por diante. De cima pra baixo.

Como testar o controller sem precisar ter a camada de negócio pronta? E como ter certeza de que o controller também está criando as entradas no Log?

É aí que entram os Mocks. Para garantir que o controller possa ser testado sem ter que implementar a camada de negócios e o Logger, mockaremos os objetos que farão o papel dos dois.

Mas o mock precisa conhecer algo a respeito do que estará simulando, para isso construiremos interfaces que representarão os nossos objetos de negócio e de Logger. Este é um aspecto interessante do uso de Mocks, ele nos induz a abstrair alguns objetos que causam dependência em outros. Como o bom funcionamento do controller depende do bom funcionamento do objeto de negócio e do logger, temos uma dependência. E o uso do Mock para suprir esta dependência exige uma interface, e esta interface abstrai a dependência em um tipo não concreto, ou seja, usando interface, temos a idéia de uma classe sem ter nenhuma noção de como ela será realmente implementada.

Pronto, temos as duas interfaces prontas. Não precisamos implementar nenhuma delas no momento, já que nosso foco está no controller. Então, vamos criar os mocks.

Observe que para criarmos os Mocks usamos o método GenerateStrictMock. No próximo Post explicarei os tipos de Mocks que podem ser criados com o Rhino.

Agora, precisamos ensinar aos Mocks o que eles devem monitorar.

O método Record() no MockRepository faz com que ele comece a gravar tudo o que você faz nos Mocks criados pelo Repositório em questão. O método ReplayAll() faz com que o repositório espere que tudo o que ele gravou seja devidamente reproduzido. O método VerifyAll() (no fim do código) faz o repositório verificar se tudo o que devia ser reproduzido aconteceu como esperado.

No caso, se rodarmos o teste agora temos um vermelho. Por que? Por que nada do que esperamos que seja reproduzido está sendo. Se copiarmos o código que é executado logo após o Record() após o ReplayAll(), o método VerifyAll() irá dizer que tudo aconteceu como esperado. Experimente.

Mas não é isso que queremos, é? Não. Queremos testar o comportamento do controller. Então agora é hora de implementarmos o código no controller. Para isto, precisaremos que o controller acesse os mocks, e aqui entra um ponto importante. Nós criamos os mocks que simulam objetos dos quais o controller tem dependência mas não estão implementados ainda (Logger e CustomerBusiness), para isso criamos duas interfaces (ILogger e ICustomerBusiness). Até aqui tudo bem.

O problema é que precisamos que o controller tenha a referencia aos mocks que criamos. Para isto existe uma técnica chamada Injeção de Dependência (Dependency Injection) mas esta técnica está fora do escopo desta série de TDD e falaremos disso em outra ocasião. No momento faremos a injeção da dependência no código mesmo através do construtor.

Remova o código que você duplicou no ReplayAll() e rode os testes novamente.

Deu verde? Não? Isso é por que a evidência que colhíamos era baseada no Id do Customer ser diferente de zero. Não precisamos desta evidência, remova a linha que faz o Assert. O Mock garante que o Controller invoca os métodos esperados e esta é a melhor evidência que temos, a evidência de que, independente do resultado, seu Controller funciona como você espera. Deu verde agora?

No próximo Post exploraremos mais o uso de Mocks, este foi só pra dar uma introdução. Até lá.

Stay sharp.

Nesta semana eu retomo os posts sobre TDD. Ainda tem algumas coisas bacanas pra explorar e provavelmente sairão uns dois posts sobre o assunto ainda esta semana. Mas enquanto estes posts não ficam prontos, eu vou postar aqui uma recomendação de download.

Este post não é meu, e sim do Waldemir Cambiucci. Estou apenas repassando:

Você que é arquiteto ou líder de desenvolvimento, que possui um time de desenvolvedores e pessoal técnico, não deixe de indicar esse material para seu pessoal:

Download de conteúdo técnico gratuito do MSDN para desenvolvedores
http://blogs.msdn.com/jpclementi/archive/2010/04/29/download-de-conte-do-t-cnico-gratuito-do-msdn-para-desenvolvedores.aspx

Entre os principais links, muito material sobre:

Azure, ASP.NET, .NET Framework 3.5, .NET Framework 4.0, Migração de Tecnologias, Silverlight 3.0 + Expression, Silverlight 4, Segurança no Desenvolvimento
SQL e Acesso a Dados, Visual Studio 2010 e .Net Framework 4.0, WCF, WF, WPF  e  Windows Server 2008.

Stay Sharp.

Como eu já disse antes, não há nada particularmente errado com a atual mania por certificação. Se você quer ser certificado pelo custo de um curso de 2 dias, dê tudo para se certificar. Se você quer certificar pessoas por assistirem seu curso de 2 dias, dê tudo para dar o curso e entregar os certificados. É tudo muito bom. Faça dinheiro. Seja frutífero e faça multiplicar.

Mas seja cuidadoso para não perder seu tempo.

Como a certificação pode ser uma perda de tempo? Isso depende do seu motivo.

• Se você está se certificando para impressionar alguém, como um gerente que está contratando, ou um recrutador, ou seus companheiros, você está perdendo seu tempo. Ninguém que valha a pena impressionar ficará impressionado com esta certificação. De fato, as pessoas que você realmente quer impressionar irão achá-la um tanto mundana.
• Se você está se certificando para ser contratado, você está perdendo seu tempo. Ninguém vai contratar você só por causa deste “C”, e ninguém para quem valha a pena trabalhar está solicitando este “C”.
• Se você decidiu contratar somente pessoas certificadas, você está perdendo seu tempo. A população de pessoas certificadas não é mais rica em talento, capacidade ou conhecimento. De fato, ela pode até ser mais pobre. Lembre-se, aqueles que tem talento não precisam de certificação da mesma forma quanto os que não tem.

Que parte da certificação não é uma perda de tempo?

• O primeiro benefício que você tem é receber instrução; mas tome cuidado: Há muitos instrutores medíocres por aí. Alguns instrutores ensinam muito bem os cursos, mas outros estão apenas torcendo que você esteja preocupado apenas com a certificação.
• Então faça uma pequena pesquisa e encontre bons instrutores. Você pode, de fato, descobrir que alguns dos melhores instrutores e cursos não oferecem certificação. Isso não deveria te impedir de considerar ter aulas com eles.

Mas espere, os instrutores não são certificados como Treinadores (trainers)?

• Claro. Eles pagam o valor e tomam aulas para se tornarem treinadores certificados.
• Mas isso não significa necessariamente que eles:
  • São bons instrutores.
  • Sabem o que ensinam.
  • Fazem o que ensinam.
  • São qualificados para ensinarem você.

Ok, mas não há algum benefício pela própria certificação?

• Claro. Um belo pedaço de papel.

Stay Sharp.

Neste post, minha intenção é dar um pouco mais de sentido à prática do TDD fazendo alguns testes em cima de uma cesta de compras. Com isto, pretendo deixar um pouco mais claro a idéia de “Especificação Executável”.

Antes de começar, preciso ressaltar que muito do que será escrito aqui se baseia nas conclusões que eu mesmo cheguei a respeito do uso do TDD, e que podem ser equivocadas. Exatamente por isto, todo o feedback é bem-vindo. Minha vida é um constante processo de aprendizado.

Ok. Admito. O exeplo do último post foi muito tosco. Mas não é fácil bolar exemplos para posts. Ou você pensa em algo muito tosco ou acaba se envolvendo em algum exemplo que levaria 40 horas para desenvolver. E ninguém tem esse tempo hoje em dia. Talvez, você goste mais dos exemplos no blog do Vinícius Quaiato. Tem gente com mais talento que eu pra pensar em exemplos rápidos.

Neste post, eu tentei reformular um outro caso para colocar o TDD em prática. Se trata de uma cesta de compras simples. Então, vamos lá.

Comecei o projeto, como esperado, pela classe de testes:

Para executar os testes, precisa-se antes implementar as classes:

E aí rodamos os testes para conferir os vermelhos.

E, agora, vamos atrás das correções para conseguir o verde.

Talvez você esteja pensando em por que eu não fiz com que o Get do TotalAmount já não fizesse a soma dos itens. É necessário entender, ou, pelo menos, foi assim que eu entendi, que o vermelho é um passo importante no seu teste. Você precisa fazer com que ele nasça falhando. E um dos meios de fazer isso é não corrigir erros que você ainda vai testar.

Pode parecer bobeira para um exemplo desse. Mas nós nos damos com situações de softwares cujo os requisitos mudam o tempo todo, e seus testes precisam indicar o impacto exato de cada mudança no requisito.

Assim, podemos seguir adiante para o próximo teste:

Aqui ficou claro a forma do por que fiz o “Get” do TotalAmount ser falho.

Agora temos o verde. Mas o que acontece se rodarmos todos os testes? O teste anterior falha devido a um erro na implementação do código. Aqui temos uma chance de aplicar um refactoring.

TDD ganha ainda mais firmeza no sentido especificação executável, quando colocamos em mente de que realmente não estamos testando, estamos especificando. Veja este próximo teste:

Você notou que agora o item possui 2 unidades na propriedade Quantity?

Ele pega o programador no pulo. Pois um programador desavisado iria facilmente cair em uma situação simples dessa, um erro inesperado. Quando fazemos dos testes especificações, colocamos neles todas as variações possíveis. É claro que eu não preciso refazer o teste com mais ítems, já que este já foi feito.

Outro teste que casa com a definição de especificação executável:

O atributo ExpectedException na declaração do método de teste faz o teste significar algo como “Quero testar se uma exceção é lançada em tal situação.” Se a exceção não for lançada, então há um problema. Isto é muito bacana. Pois até mesmo as exceções fazem parte da especificação.

Para não parecer uma especificação tão incompleta, podemos acrescentar mais um testezinho…

Experimente especificar mais testes para esta solução, ou invente uma e pratique. Chega a ficar divertido depois que nos acostumamos.

Conclusão

Quanto mais incremento minha especificação, mais aumento a testabilidade do meu software. Com a ajuda do TDD, fica fácil saber se o software obedece a especificação: basta rodar os testes e esperar tudo verde.

No próximo post falaremos de uma abordagem do TDD que visualiza sua aplicação sob outra perspectiva: o Comportamento (BDD).

Stay Sharp.

E para saber fazer bom uso dele é necessário entendermos uma coisa simples: TDD é de Test-Driven Design. Mas o que muita gente faz é focar no T de Test e esquecer do D de Design. Não se iludam: o T é o aspecto menos importante da sigla. O que realmente importa para nós aqui é o segundo D do TDD.

Antes de começar, preciso ressaltar que muito do que será escrito aqui se baseia nas conclusões que eu mesmo cheguei a respeito do uso do TDD, e que podem ser equivocadas. Exatamente por isto, todo o feedback é bem-vindo. Minha vida é um constante processo de aprendizado.

Test First

Testabilidade é a consequência. É o efeito do uso do TDD. Mas, embora seja Efeito ela também é a Causa. No TDD, para que o fim seja alcançado, o fim precisa ser o meio. A causa se torna efeito. Qual o fim? Obter um software testável. Qual o meio? Testar meu software antes de escrevê-lo.

Por que?

Por que à medida que escrevo meus testes, consumo meu software antes de escrevê-lo. E, a medida que faço isso, entendo como deverei escrevê-lo. Por isso que, no fim de tudo, TDD se trata de Design, pois o Design de meus objetos obedecem a forma como eu os consumo, e não o contrário. Ou seja, mudamos a perspectiva de codificação. Não fazemos a assinatura de um método baseando-se em como ele enxerga a si mesmo, mas baseando-se na perspectiva de quem irá usá-lo.

Quais os benefícios disso? Aumento na qualidade da entrega, Aumento na Coesão e redução do Acoplamento.

Para quem não sabe: Um método com alta coesão é um método que sabe resolver sua responsabilidade de forma bem resolvida e nada além disso. Um método com baixo acoplamento é um método que não está amarrado ao mundo externo a ele. Não tem conhecimento sobre aquilo que não controla.

Um exemplo da aplicação de coesão, é um método que precisa enviar um flyer por e-mail a um usuário. Falamos de 3 coisas: Flyer, E-mail e Usuário. Se fizermos um único método capaz de resolver as 3 coisas, ele resolverá o problema, mas terá uma coesão baixa, ou seja, ele faz mais do que um único método deveria fazer. Assim, deveríamos criar um método que saberia resolver o Flyer, um outro que saberia resolver o usuário, e um terceiro que saberia enviar um e-mail recebendo o endereço de e-mail do usuário destinatário e o código HTML do flyer para colocar no corpo do e-mail. Assim, teríamos 3 métodos que resolvessem os 3 problemas da situação proposta, cada um com sua própria responsabilidade e com alta coesão. O benefício da alta coesão é: E se eu quiser permitir que meu usuário possa acessar o flyer através de uma url impressa no e-mail, caso ele não consiga visualizar o e-mail corretamente, o mesmo método que resolve o HTML do Flyer para enviar o e-mail pode ser utilizado nesta url. E se eu quiser mandar um outro e-mail para meus usuários para um outro fim, o método que resolve o e-mail pode ser reaproveitado.

Um exemplo de aplicação do acoplamento (ou da redução dele) é fazer com que o método que envia e-mails alimente um Log da aplicação. Ora, de acordo com a coesão já vimos que não é saudável fazer com que este método resolva este problema. Está além da responsabilidade dele. Mas precisamos de um log, então deixamos a coesão de lado e implementamos um Log para o envio de e-mails e também para o caso de haver algum erro durante o procedimento. O log que aplicamos cria entrada em um arquivo Texto “LogEnvio.txt”. Quando fazemos isso, criamos um acoplamento no método. Ele fica dependente do acesso ao arquivo LogEnvio.txt. De fato, ele pode até ter êxito no envio de e-mail, mas algum problema na gravação do log pode prejudicar o bom funcionamento do método. Para reduzir este acoplamento, a boa prática nos fala que o melhor que podemos fazer é tornar o método que envia e-mail o mais ignorante possível a respeito do mecanismo de Log. Existem práticas para alcançar este objetivo, mas elas estão fora do escopo deste post. Eu só quis dar um resumo de coesão e acoplamento.

E o que isso tem a ver com testabilidade? Não poderia criar um design com alta coesão e baixo acoplamento sem o TDD?

Sim. Você poderia. Mas com o TDD, a alta coesão e o baixo acoplamento são atingidos naturalmente. você aumenta a coesão do seu método na hora de fazer com que seus testes avaliem somente o que ele é responsável por fazer. Você reduz o acoplamento na hora de fazer com que seus testes simulem situações que estão fora do controle do seu método. Como testar, por exemplo, o que acontecerá quando o banco de dados não funcionar? Se codificarmos o acesso aos dados antes dos testes, provavelmente não pensaríamos nisso. Mas quando fazemos os testes primeiro, entendemos que haverá esta situação para testar, e então permitimos o controle do acesso ao banco por fora do método, e assim conseguimos simular uma falha no acesso ao banco sem precisar mexer no banco propriamente dito.

Ao fazer testes antes, pensamos no uso do método em todas as situações possíveis, e assim ganhamos, além da testabilidade, a chance de aplicar alta coesão e baixo acoplamento durante o desenvolvimento como consequência do design elaborado de acordo com os mesmos testes.

E aí entra a letra T do TDD. Se você é capaz de elaborar os testes necessários para avaliar todo o funcionamento do seu objeto, então você é capaz de fazê-lo de acordo com a forma que estes testes o consome, e assim você terá um objeto totalmente testável (a ponto de te tornar capaz de dizer se ele realmente funciona ou não) e com um design totalmente dirigido ao consumo, a ponto de tornar seu uso realmente fácil na hora de implementar os métodos que o consumirão.

Tal prática torna seus testes o que a comunidade batizou de “Especificações Executáveis”. Ou seja, se eu sou capaz de entender todas as situações esperadas para determinar se meu código realmente funciona ou não, então sou capaz de transcrever estas situações na forma de testes, e se sou capaz de rodar estes testes sobre o meu código para saber se todos eles são bem-sucedidos, então significa que meus testes podem determinar se meu software realmente funciona ou não. Sendo assim, se meus testes dizem se o meu software funciona, então meus testes servem de especificação. Toda vez que executo meus testes, estou, na verdade, verificando se meu software obedece à especificação que os meus testes estabeleceram.

Vamos ilustrar

Preciso de um método que inclua um cliente no sistema. Assim, crio uma classe de repositório de clientes e defino um método Incluir, que recebe uma instancia de Cliente. Para saber se este método funciona eu preciso verificar se ele realmente incluiu o cliente no repositório. Mas, digamos que o cliente esteja lá. Isto significa que o método funciona?

Não, necessariamente. O que acontece se o banco estiver offline? Como esperamos que o método se comporte? E se o objeto estiver inválido? E se o Cliente que estamos tentando incluir já existe no Repositório? Todas estas perguntas determinam como o método deveria funcionar. Isto significa que a resposta para estas perguntas é a especificação do método. Se o resultado obtido após executar o método atende a todas as condições impostas pelas respostas, então o método está seguindo toda a especificação.

É por este motivo que o Giovanni Bassi, em seu blog, resolveu escrever um texto cujo o título é: TDD não existe.

(…) TDD não existe, porque não são testes que dirigem o desenvolvimento, mas sim especificações, e há uma grande diferença, porque nem sempre testes são especificações. Um nome mais adequado seria Specification Driven Development, ou Specification Driven Design (SDD). (…)

De fato, existe uma outra abordagem  do TDD batizada de BDD (Behavior-Driven Design), e falarei a respeito disso durante esta série de posts sobre TDD. 

Como aplico isso?

Simples assim: antes de criar a classe que precisa, crie uma que executará os testes sobre ela.

Nos exemplos que mostrarei neste Post, irei fazer uso do MsTest, que já vem em algumas versões do VisualStudio. Mas prometo em breve colocar posts pra falar de outras ferramentas de teste para servirem de alternativa para quem não tem uma versão do VisualStudio com ferramenta de testes integrada.

A aplicação do TDD se resume em 3 partes de um ciclo: Primeiro faça um teste que falhe (vermelho), depois faça com que ele funcione (verde) e depois aplique possíveis melhorias ao código.

Vamos lá:

Neste exemplo mostrarei como fazer um teste. Mas isso ainda é longe de ser a real aplicação do TDD, que será evoluída no decorrer desta série de Posts.

1. Crie um novo projeto do tipo Class Library

2. Adicione à solution um projeto de teste

3. Insira uma referência ao projeto Class Library no projeto de Testes

4. Renomeie o método de Teste para indicar o que está sendo testado

5. Escreva o teste

Os testes normalmente são escritos em 4 etapas:

• Setup

É onde todo o ambiente necessário para a execução do Teste é preparado. Conexão com o banco, ou classes de Log, enfim, tudo o que é necessário ter em mãos para executar o teste.

• Exercise

É a execução do teste propriamente dito. Aqui invoca-se tudo o que se pretende invocar.

• Verify

É onde são colhidas as evidências de que o teste realmente funcionou.

• Tear down

Tudo o que foi inicializado no Setup e precisa ser derrubado, é feito aqui.

Obviamente não adianta rodar o teste. Afinal, as classes ainda não existem. Mas pelo código do teste, você já sabe quais classes, propriedades e métodos precisa criar. Então, vamos criar as classes Customer e CustomersRepository no projeto ClassLibrary criado anteriormente.

Somente o suficiente para realizar o teste. Observe que os métodos Insert e SelectByName não foram implementados.

6. Vermelho

Execute o teste. Se você usa a ferramenta de Testes do VisualStudio, vá ao menu Test, aponte Run e clique em Tests in Current Context.

Observe o aviso de Failed na janela Test Results, com um ícone vermelho. Você também pode verificar os detalhes da falha clicando com o botão direito no resultado do teste.

7. Implementar os métodos

Não se esqueça que também é necessário criar o banco e a tabela customers para que o teste funcione.

8. Green

Execute os testes novamente.

Verifique agora na que o Resultado do teste é um ícone Verde. O código passou no teste.

9. Refactoring

Agora que o código passou no teste, podemos aplicar algum refactoring. Por exemplo, nos dois métodos usamos uma mesma conexão. Então podemos reaproveitar o objeto de conexão. E já que pensamos assim, o objeto de conexão pode ser injetado no construtor.

10. Alterando o teste para atender ao código refatorado.

11. Verde de novo

Execute o teste novamente e, caso surja um novo vermelho, reveja suas alterações até que o seu código passe pelo teste.

E agora?

Apesar de termos visto um rápido exemplo de como fazer testes e executá-los, este não é um bom exemplo de aplicação de TDD. À medida que evoluimos na prática do TDD começamos a entender melhor o conceito de especificação executável a ponto de, por exemplo, já criar logo de cara o construtor do repositório recebendo o objeto de conexão.

No TDD, a idéia é fazer testes que não mudam, a menos que a especificação mude. Então é natural que com o tempo identifiquemos estas pequenas coisas antes mesmo de chegar ao refactoring. Em resumo, o teste tem que resultar vermelho em primeiro lugar, depois há de se fazer o estritamente necessário para torná-lo verde, e então se aplica o refactoring para melhorar o código.

O nosso verde neste exemplo não significa, ainda, que o nosso código realmente funcione. Não aplicamos o TDD corretamente, apenas fizemos um teste. Quer uma prova?

Abra a tabela customers e verifique:

Vai notar que para cada vez que você executou o teste com resultado verde, um novo registro foi inserido na tabela. Isso resulta na redundancia de registros, e isto não é bom. Além disso, nosso código não tem nenhuma tolerância a falhas. Se houver algum erro devido a conexão com o banco ou qualquer outra coisa, não há nada acontecendo e nosso teste é incapaz de avaliar isto.

Para reverter esta situação existem práticas que aprenderemos no decorrer desta série.

Conclusão

A forma como codificamos nossos testes determina a forma como codificaremos nossas classes, e isto nos ajuda a criar classes que nos provêm recursos que serão realmente utilizados da maneira como se espera ao consumí-las. A prática do TDD nos ajuda neste objetivo e ainda nos dá, como consequência, um código testável, alta coesão e baixo acoplamento.

Nos próximos posts, evoluiremos nestes objetivos.

Stay sharp!

Links úteis

TDD não existe (http://unplugged.giggio.net/unplugged/post/TDD-nao-existe.aspx)
Texto de Giovanni Bassi sobre TDD.

BubbleSort Kata (http://unplugged.giggio.net/unplugged/post/BubbleSort-Kata.aspx)
Exemplo de BubbleSort aplicando TDD.

TDD (http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c/)
Post de Vinícius Quaiato dando exemplos de aplicação do TDD.