O que significa TDD e qual é o seu benefício    

Olá pessoal!

Hoje vou publicar um mini artigo que fiz para a pós-graduação ano passado sobre TDD. Se fosse escrever hoje sobre o mesmo assunto, com certeza falaria de muitas coisas diferentes, mas neste post vou colocar o artigo exatamente como entreguei na faculdade. Provavelmente voltarei a abordar esse tema por aqui, e ai sim colocarei mais informações. Por ser um artigo acadêmico, ele é bem superficial e não técnico. Segue o texto na íntegra.


O que significa TDD e qual é o seu benefício

Fazer software com qualidade não é uma tarefa fácil. Especificações mal definidas e que mudam sempre, tecnologias e conhecimento sempre em evolução e mais uma série de fatores torna a construção de software uma tarefa muitas vezes ingrata. Quando dizemos Software de qualidade, temos que ter em mente que qualidade não é medida apenas por experiência do Usuário ou grau de completude da especificação funcional. Qualidade de Software deve contemplar todos os aspectos do mesmo, como o código. Em código temos vários outros fatores que podemos citar, como legibilidade, complexidade, desempenho e o que mais interessa esse artigo, manutenção. Uma manutenção difícil em código pode acabar com o funcionamento de um sistema e causar perdas inestimáveis.

Teste é a principal ferramenta para alcançar a qualidade de Software. Ao longo de um desenvolvimento de Software, vários tipos de testes são executados, cada tipo é especifico para uma fase do desenvolvimento. Para o escopo do código, o tipo de testes apropriado é o Teste de Unidade ou Unitário, que visa validar cada pequeno trecho de código e conferir que ele está executando conforme esperado. Em um cenário onde a mudança é constante esse risco deve ser mitigado ao mínimo e Test-Driven Development (TDD) ou Desenvolvimento Orientado a Testes, é uma ferramenta que se encaixa perfeitamente nesse cenário. TDD é a prática de desenvolver Testes Unitários antes de desenvolver a unidade, para dessa forma direcionar o desenvolvimento da unidade.

“Código limpo que funciona é o objetivo do TDD. Código limpo que funciona é um objetivo que vale a pena por uma série de razões: Prediz a forma de desenvolver. Você sabe quando terminou, sem a preocupação de uma lista de erros. Permite seu time confiar em você. Melhora a vida do seu usuário. Possibilita aprender do seu código tudo que ele tem para te ensinar.” [1]

TDD prega que você deve codificar o teste do seu código antes mesmo de escrevê-lo, dessa forma, a primeira pergunta que você deve fazer ao iniciar o desenvolvimento não é “Como devo desenvolver este código”, mas sim “Como devo testar esse código”. Um dos benefícios dessa abordagem é que ao pensar nos testes, o desenvolver irá desejar códigos fáceis de testar, dessa forma com os testes prontos, ele será forçado a desenvolver um código limpo, desacoplado, do contrario será muito difícil realizar o teste.

Todo software de qualidade tem a maior parte do seu código testado, métrica essa chamada de Code Coverage. Com o TDD, você tem a certeza que 100% do seu código está testado, pois ele só foi escrito depois que você o testou. Comprovadamente, você gastará menos tempo com código testado ao alterá-lo do que com código sem testes. Código sem teste é legado para o próprio desenvolvedor que o desenvolve.

“Você provavelmente terminará o seu sistema com o mesmo número de linhas de testes que o número de código funcional quando implementar TDD. Para TDD fazer sentido economicamente, você precisa estar apto a desenvolver duas vezes mais linha de código por dia ou a metade de linhas para desenvolver a mesma funcionalidade” [1]. Quando uma pessoa está iniciando em TDD, é normal se questionar apenas com a realidade de ter que desenvolver mais rápido, e isso motiva muitos profissionais a desistirem dessa técnica. Porém, como afirmado anteriormente, o código desenvolvido com TDD é mais limpo, simples e enxuto, logo, no maior número de vezes, o seu código é que vai cair pela metade no número de linhas, e não sua produtividade terá que aumentar.

Ainda que seu código não diminua, em muitos casos você não terá que aumentar a capacidade de velocidade de desenvolvimento, pois se você desenvolver cem linhas de código com testes perderá X tempo para realizar manutenção no mesmo, por outro lado, se você fizer o mesmo número de linhas de código sem testes, o tempo que perderá para fazer manutenção em algum código é imprevisível, mas será sempre maior que X.

Podemos saber que está na hora de começar a desenvolver testes para nosso código no momento que o nível de Stress para realizar uma manutenção nele for alto. Ou seja, quando o desenvolvedor ao deparar com um código necessitado de manutenção o Stress do time aumenta? Então você não sabe o que está falhando. Esse sentimento é comum em projetos sem testes, com TDD o nível de Stress de uma equipe tende a zero, pois o erro é rapidamente explicitado por testes, e você sabe exatamente o momento que a manutenção está completada, pois os novos testes criados antes das alterações estarão passando. Para implementar TDD em uma equipe, comece com indicadores que mostre o nível de Stress ou Medo da sua Equipe. Mostre a evolução desse índice conforme o TDD for sendo adotado.

Todas as práticas utilizadas em testes devem ser adotadas em TDD, como testes isolados, simples, etc; mas com TDD alguns outros passos também devem ser considerados, tais como fazer pequenos passos (baby steps), não ter pressa de fazer um teste passar, etc. Essas são boas práticas que facilitam a vida de pessoas iniciantes no Desenvolvimento Orientado a Testes, mas que devem ser seguidas por todos os desenvolvedores experientes. “Escaladores conservadores têm uma regra de que pelo menos três dos quatro membros do corpo devem estar presos à montanha ao mesmo tempo. Movimentos rápidos onde são tirados dois membros ao mesmo tempo são muito arriscados.” [1]. Essa mesma regra deve ser seguida por desenvolvedores, não ter pressa de pular os pequenos passos ao desenvolver os testes, dessa forma, terá certeza que a maior parte do código está sendo testado, e seu Nível de Medo será praticamente zero ao entregar o software.

Apesar de TDD ser muito aplicado quando o time segue Metodologias Ágeis de desenvolvimento, essa técnica pode e até mesmo deve ser adotada por qualquer tipo de time, como aqueles que utilizam RUP, por exemplo. Com testes, você pode confiar em refatoração, Builds automáticos, e com TDD você pode confiar, além de tudo isso, que seu time entrega software não só que roda, mas que faz o que é certo, pois você codificou o que ele precisava fazer de acordo com um teste previamente escrito, e não testou algo que já estava escrito sem garantia que ele fizesse o que deveria.

Com TDD, concluí-se que é possível fazer “código limpo que funciona” e que é possível ser agradável criar software de qualidade sem altos níveis de Stress.

[1] Beck, Kent; Test-Driven Development by Example. Addison Wesley,2003


É isso. Até o próximo post.

31. janeiro 2013 09:21 by Frederico B. Emídio | Comments (0) | Permalink

Introdução a Asp.Net WebAPI    

No período de inatividade do Blog, muitas coisas aconteceram no Asp.Net, inclusive uma nova versão foi lançada com muitas melhorias. O Diagrama que mostrei neste post já está desatualizado e vou tentar correr atrás do tempo perdido para falar de alguns temas por aqui.

Introdução

O Asp.Net já está bastante consolidado com uma arquitetura sólida e extensível, permitindo o desenvolvimento seguindo diversos padrões e paradigmas. Como mencionado no post citado, sobre o Asp.Net existem varias outras camadas que possibilitam diferentes abordagens para desenvolver diferentes tipos de projetos, sendo que todas elas são válidas de acordo com o objetivo da aplicação. De forma rápida podemos citar algumas destas formas de desenvolvimento que o Asp.Net fornece: Web Forms, Asp.Net MVC, Dynamic Data, Web Pages e agora também o Asp.Net WebAPI. É exatamente sobre essa última forma que falaremos ao longo desse post . Farei aqui apenas de uma introdução teórica, e nos próximos posts mostrarei alguns exemplos.

É comum, quando ouvimos falar de tecnologias Web, pensarmos em sites ou sistemas que rodem em Browser, porém, Web é muito mais que isso. Arquiteturas de Nuvem, como o Azure da Microsoft ou o AWS da Amazon são bons exemplos de cenários onde hospedamos serviços na Web, com o objetivo de serem consumidos de qualquer origem, e não apenas de sites. Esse tipo de arquitetura orientada a serviço (SOA na sigla em inglês) além de fornecer um grande ganho em escalabilidade, sazonalidade, especialização, entre outros benefícios, pode ser consumido por muitos tipos de aplicações, como Windows, Cobol, Console ou qualquer outra tecnologia que não rode em Browser e necessite de dados centralizados e serviços dedicados.

Um bom exemplo de aplicação que consome serviços na Web em grande escala, e que é muito popular nos dias de hoje, são os aplicativos para SmartPhone. A grande maioria desses aplicativos está sempre conectada, consumindo serviços e exibindo-os para o usuário como se eles fossem locais.

Imagine agora você ter uma ótima ferramenta para prover serviços para toda essa gama de aplicativos, seguindo sempre uma mesma arquitetura e o mesmo padrão. Foi pensando nisso que a Microsoft criou o Asp.Net WebAPI, que nos dá todas as ferramentas e facilidades necessárias para conseguirmos alcançar todos esses objetivos

Como o próprio nome diz, WebAPI é forma que a equipe do Asp.Net nos dá para disponibilizar uma API (Application programming interface) hospedada na Web, ou seja, abrir uma porta na sua aplicação para que outras aplicações e serviços possam interagir com ela por meio de serviços HTTP. Para quem é desenvolvedor Windows esse conceito é muito comum, pois muitas vezes dependemos de APIs do sistema operacional para desenvolver alguma funcionalidade mais avançada.

Entendendo Asp.Net WebAPI

O Asp.Net WebAPI, diferente de outras tecnologias Web da Microsoft, como o WebForms, Asp.Net MVC ou WebPage, não é construído diretamente sobre a plataforma Asp.Net, ele é, na realidade, uma abstração feita sobre o Asp.Net MVC 4. Isso quer dizer que além de você fazer uso de toda a tecnologia compartilhada pela base do Asp.Net, você terá em mãos também toda a tecnologia especializada e já consolidada do Asp.Net MVC. Na prática, um projeto Asp.Net WebAPI é um projeto Asp.Net MVC com itens/arquivos a mais. Ele contém toda a configuração padrão de um projeto MVC normal. Isso é muito proveito, uma vez que você poderá fazer um site e no mesmo projeto disponibilizar serviços padronizados.

Encontramos no Asp.Net WebAPI termos muito comuns de aplicativos Asp.Net MVC simples. Por exemplo, nossos métodos são expostos através de Controllers e são alcançados através de Rotas, as diferenças estão basicamente em classes bases, que são específicas para cada camada.

Os Controllers do WebAPI, por exemplo, herdam de ApiController ao invés de simplesmente Controller, que é o caso dos controllers de uma aplicação padrão MVC. Por sua vez, os controllers do WebAPI não retornarão Views como ActionResult, pois não é esperado que serviços retornem telas ou relatórios, mas apenas dados. As Rotas também têm diferenças: sua configuração se dá através do método routes.MapHttpRoute ao invés do routes.MapRoute, dessa forma permitindo que o mesmo aplicativo/site tenha rotas configuradas para o WebAPI e para Controllers MVC padrões.

É interessante saber também que com o WebAPI você não precisa ter uma infraestrutura Web disponível para sua aplicação, ou seja, você não precisa do IIS para disponibilizar seus serviços REST em um protocolo HTTP. Com poucas linhas de código você consegue expor serviços em um Console Application, ou outro tipo de aplicação .Net, fazendo o que é chamado de Self-Host WebAPI. Apenas baixando um pacote no NuGet você já tem tudo que precisa para criar serviços sem IIS, apenas com o .Net instalado.

O que são serviços REST?

Você deve ter reparado que comentei algumas vezes de serviço REST até agora no post. Isso porque o WebAPI foi criado principalmente para geração de serviços REST. Apesar de ter citado o termo algumas vezes, ainda não deixei claro o que seria esse tipo de serviço. Tentarei agora fazer uma breve explicação desse conceito de serviço, já muito utilizado por diversos desenvolvedores, mas que é sempre bom ser esclarecido.

Já ficou evidente que o principal ganho ao desenvolver projetos com Asp.Net WebAPI é a facilidade em desenvolver serviços REST (Representational State Transfer). Apesar desse não ser o único tipo de serviço web possível com WebAPI, nitidamente essa é o tipo de serviço recomendado pela Microsoft ao utilizar WebAPI, como veremos a seguir. Para desenvolver serviços RPC (Remote Procedure Call), por exemplo, os WebServices ASMX ou WCF já são bem aptos e fáceis, enquanto que, por outro lado, desenvolver serviços REST em ASMX ou WCF não é tão simples como com WebAPI.

Para quem não sabe, a grande diferença entre serviços REST e RPC é que enquanto em REST os serviços expõem seus dados como recursos em URI e os clientes interagem com esses dados através de verbos HTTP, em RPC os serviços expõem diferentes métodos organizados de forma aleatória em uma ou mais URIs.

Por exemplo, um serviço REST teria sempre a mesma URI no formato MeuEndereco/MeuDado e de acordo com o verbo HTTP (POST, GET, PUT, DELETE), a aplicação poderia responder as requisições do Cliente sobre o “MeuDado”. Ou seja, o cliente pode obter um registro através do verbo GET ou salvar o mesmo registro com o verbo Put ou Post.

Por outro lado, no RPC, se fosse implementado em ASMX, seria algo assim MeuEndereco/MeuServico/ObterDado, MeuEndereco/MeuServico/SalvarDado, MeuEndereco/MeuServico/OutroMetodo, etc. Perceba que o final do endereço é um Método, e não um recurso, como é o caso do REST.

Serviços REST são muito úteis para expor serviços com a função CRUD sobre um dado, pois os principais verbos HTTP servem exatamente como os principais comandos SQL (SELECT, INSERT, UPDATE e DELETE). Mas é importante ter em mente que serviços REST não estão restritos a apenas operações CRUD.

Quando criamos um serviço REST, respeitamos todas as formas de comunicação estabelecidas pelo protocolo HTTP. Visitando esse post você pode ter uma noção de como funciona o HTTP. Além disso, você pode encontrar todos os códigos de Status pré-definidos em diversos sites da Web. No .Net existe o enum HttpStatusCode, no namespace System.Net o nome e o código de todos esses Status.

Também precisamos ter em mente ao modelarmos serviços REST que eles devem ser planejados para não ter estados, como Sessions, e devido a isso, cada Requisição deve ter toda a informação necessária para que o servidor possa processar a mensagem. E para ser padrão, ele deve retornar dados compreendidos na maioria das linguagens, ou seja, ele deve retornar geralmente XML ou JSON. É muito comum, quando criamos serviços seguindo o padrão REST, chamá-los de RESTFul.

Em quais situações utilizar o WebAPI?

Não é difícil responder a pergunta “Em quais situações utilizar o WebAPI”. Por ser um framework de serviço, qualquer oportunidade de utilizar uma camada de serviço pode ser exposta via WebAPI. Eu já citei o uso em SmartPhones, que talvez seja o mais comum, mas podemos encontrar muitos outros lugares. Sites como o Twitter, por exemplo, disponibilizam uma API inteira para nossos softwares interagirem com seus serviços. Sites de notícias pode disponibilizar APIs que vão além da funcionalidade exposta por um RSS, por exemplo, possibilitando sistemas de terceiros ranquearem e comentarem notícias. Aplicativos de SmartTV também têm se popularizado e também são consumidores de APIs. A lista seria enorme se colocássemos todas as possibilidades.

O importante é saber o que o WebAPI oferece e dessa forma poderíamos visualizar oportunidades de aplicação de serviços feitos em WebAPI em ainda mais lugares.

Por exemplo, é possível expor serviços OData via WebAPI de forma tão simples quanto expor serviços RESTFul simples. Para alcançarmos tal objetivo, precisamos apenas retornar um interface IQueryable em nossos métodos, que a aplicação cliente teria condições de pesquisar, ordenar e filtrar os registros de forma automática.

Obs: OData (Open Data Protocol) é um protocolo Web para pesquisar e atualizar dados através de tecnologias conhecidas na Web. É uma forma, por exemplo, de expor tabelas um Banco de Dado direto no protocolo HTTP e permitir que as consulta sejam feitas diretamente via HTTP.

É isso pessoal, hoje apenas introduzi o Web API, nos próximos posts mostrarei alguns exemplos.

Até logo!

15. janeiro 2013 04:13 by Frederico B. Emídio | Comments (0) | Permalink

Testando propriedades e métodos privados com PrivateObject.    

Olá pessoal! Estou retomando o Blog em 2013 e agora pretende realmente manter a regularidade.

Para iniciar essa nova fase vou falar de um assunto importante já abordado aqui de forma rápida, e que esse ano talvez eu dê mais foco: Testes. Hoje vou falar de uma característica bem específica dos testes, que é a dificuldade de testar propriedades e métodos privados.

De forma geral, é dito que propriedades e métodos privados e não precisam ser testados porque em teoria o método público que acessa o método privado uma vez testado, também testará o método privado. Infelizmente na prática muitas vezes precisamos testar esses métodos privados, talvez porque a lógica deles seja complexa, ou porque o design da classe não seja bom, ou mesmo porque a classe não é nossa, e não podemos alterá-la, mas precisamos testá-la.

O que devemos ter em mente é que nossos códigos precisam ser testados, e devemos fazer de tudo para que isso seja possível, seja com Mocks, Stubs ou até testando métodos privados.

Vamos ao código!

No exemplo abaixo apenas vou mostrar como testar, ignore a necessidade do método ser privado ou não, ou se eu podia fazer um código diferente, o objetivo aqui é mostrar a possibilidade do teste quando ele se faz necessário.

Minha classe de exemplo que deve ser testada:

   1:  public class ClasseTestada
   2:  {
   3:      private int SomaPrivado(int a, int b)
   4:      {
   5:          return a + b;
   6:      }
   7:  }

E o meu teste:

   1:  [TestMethod]
   2:  public void Testar_a_Soma_de_dois_numeros()
   3:  {
   4:   
   5:      var a = 2;
   6:      var b = 3;
   7:      var expected = 5;
   8:   
   9:      var teste = new ClasseTestada();
  10:      var pv = new PrivateObject(teste);
  11:   
  12:      var actual = (int)pv.Invoke("SomaPrivado", a, b);
  13:   
  14:      Assert.AreEqual(expected, actual);
  15:  }
  16:   

E o resultado

Resultado do Teste

Vejam que o teste passou como o esperado. O segredo é bem simples. Apenas utilizo a classe PrivateObject, essa classe basicamente utiliza reflection para invocar métodos e propriedades. Uma vez que passo minha instância a ser testada no construtor da PrivateObject, posso utilizar seus métodos para chamar os membros da classe a ser testada. No caso do exemplo acima estou utilizando o método Invoke para invocar um método privado.

Essa classe pertence ao Namespace Microsoft.VisualStudio.TestTools.UnitTesting, que fica automaticamente disponível ao criar um projeto de testes. Ela tem uma série de outros métodos que auxiliam no trabalho de acesso a membros privados. Abaixo tem toda a lista de métodos:

clip_image003

É isso. Bem simples e curto para começar o ano e retomar as postagens, mas em breve tem mais.

Abraços e feliz ano novo!

10. janeiro 2013 01:13 by Frederico B. Emídio | Comments (0) | Permalink

Sobre mim

Minha Imagem

Meu nome é Frederico Batista Emídio, trabalho com desenvolvimento de sistemas profissionalmente a oito anos, porém, já faço sites pessoais a pelo menos dez anos.

Para saber mais clique aqui.

Páginas

Calendário

<<  novembro 2017  >>
seteququsedo
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Visualizar posts em um Calendário
Sigua @fredemidio

MCP Asp.NET