As new versions of Restfulie come up, it becomes more clear which extension points are important and should be easy to be used, the media type and http results are two of those aspects that Restfulie C# tries to help the developers by allowing them to write classes focused on one task only as we shall see here.

A simple C# Item model can be rendered in your controller as in ruby and java:

[ActAsRestfulie]
public class ItemsController : Controller
{
private MemoryDatabase database;

public ItemsController()
{
  database = new MemoryDatabase();
}

public virtual ActionResult Index()
{
  return new Ok(database.List());
}

public virtual ActionResult Get(int id)
{
  var item = database.List().Where(i => i.Id == id).SingleOrDefault();
  if (item == null) return new NotFound();
  return new OK(item);
}
}

If you want to add some link relations to any resource, simply let your model implement IBehaveAsResource and add the SetRelations method:

public class Item : IBehaveAsResource
{
public void SetRelations(Relations relations)
{
  relations.Named("self").Uses().Get(Id);
  relations.Named("origin").At("http://www.some-fabric.com/");
}
}

The http GET request to an item with application/json in the accept header will now return:

{"Id":1,"Name":"Pencil","Price":"1.50",
"links":[{"rel":"self","href":"http://localhost:1198/Items/1"},
{"rel":"origin","href":"http://www.some-fabric.com/"}]}

But we know relations work in different ways with different media types (and the Link header) so you might want to add your own media type marshaller/unmarshaller, which is capable of understanding a new media type. Restfulie C# comes with support for application/json, application/xml and application/atom+xml.

If you want to add your own result, simply implement a RestfulieResult using a series of decorators to your new result:

public class OK : RestfulieResult
{
public OK() { }
public OK(object model) : base(model) { }

public override ResultDecorator GetDecorators()
{
  return new StatusCode((int)HttpStatusCode.OK,
    new ContentType(MediaType.Synonyms.First(),
    new Content(BuildContent())));
}
}

This release documentation is already out and the download can also be done at github.

Restfulie C# requires the dot net framework 3.5+, and uses castle in order to create dynamic proxy for setting up relations.

Obrigado a quem compareceu na apresentação! Os slides estão aqui!

Desvios comuns em TDD

View more presentations from mauricioaniche.

Qualquer dúvida, sugestão, crítica, por favor me mandem!

TDD é uma atividade de design. O teste de unidade que você escreve serve basicamente para definir suas expectativas em relação ao código que você vai escrever. E, ao fazer isso, você pensa não só no nível da implementação do algoritmo, mas em um nível um pouco mais alto: no nível de design. TDD permite que você brinque e experimente diferentes possíveis designs, dando feedback rápido sobre o resultado obtido, até que você encontre o design ideal para aquela situação.

Ou seja, quando você faz TDD, você pensa exclusivamente em design e não em testes. É uma prática de suporte para design de software.

Mas… É claro que você precisa testar! Você não apaga os testes que você produziu usando TDD, óbvio. Mas muito provavelmente eles não testam todas as possibilidades possíveis. E é aí que outras técnicas entram em cena, e você pode encontrar muita informação sobre elas em [1][2].

Resumindo, use TDD quando você precisa trabalhar no design de determinada classe ou módulo. Quando você estiver satisfeito com design, é hora de testar! Aí você pode fazer test-first, test-last, ou que você preferir, mas teste de verdade!

[1] The Art of Software Testing – Myers
[2] Introdução ao Teste de Software – Maldonado, Delamaro, Jino

O keynote foi feito pelo Steve Freeman, autor de um dos melhores livros de OO e TDD que já li (Growing Object-Oriented Software, Guided by Tests). Ele basicamente mostrou seu ponto de vista sobre TDD. Segundo ele, “programação comum está para TDD assim como programação procedural está para programação orientada à objetos”. Foco bem definido, bom feedback e progredir sem medo também foram citados como vantagens. Uma citação muito interessante, e que venho pensando há muito tempo sobre como transmitir essa idéia é a de que “o programador deve entender o porquê TDD funciona; caso contrário, é apenas burocracia”.

Em seguida, o aluno de mestrado Theodore Hellman nos apresentou a ferramenta que seu grupo desenvolve em Calgary, Canadá. Ela testa interfaces de uma maneira muito interessante: antes de desenvolver cada interface, o programador faz protótipos na ferramenta, desenhando caixas de texto, botões (parecidos com os que desenhamos no papel). A mágica acontece depois que o protótipo está pronto: você testa o protótipo, clicando nos botões e digitando valores nas caixas de texto fictícias, e a aplicação os executa na aplicação real! O problema é que funciona apenas para aplicações .NET Windows Forms.

Em seguida a apresentação do John Clements (um dos criadores do Dr. Scheme) e do David Janzen (professor da Politecnica da California, possui muitas publicações relacionadas a experimentos com TDD) sobre o quão difícil é ensinar TDD para os alunos. Apresentaram algumas técnicas de ensino e problemas que já tiveram nas primeiras aulas sobre o assunto.

O alemão Florian Barth, da Universidade de Manheim, mostrou a ferramenta para testes de aceitação que seu grupo trabalha. É uma mistura de Fitnesse com linguagem de programação, onde você escreve não só os casos de testes como a implementação do teste em planilhas. É bem interessante, já que basicamente elimina o trabalho de codificação dos testes. O problema é que algumas coisas ainda são um pouco complicadas e exigem um trabalho extra na planilha. Mas sem dúvida é um projeto para ficar de olho.

Robert Chatney apresentou seu framework LiFT, uma DSL para testes de aceitação em Java, inspirada no Cucumber. Ela faz com que seus testes em Java fiquem muito fluentes. Totalmente extensível, é um projeto que pretendo colaborar em breve. O código pode ser encontrado no Google Code.

Em seguida, apresentei meu paper sobre erros (ou desvios) que os programadores cometem quando praticam TDD. Apesar de algumas críticas em relação à metodologia (problemas esses que já eram conhecidos e estavam na seção de “ameaças a validar” do paper), as ideias ali foram elogiadas e todos concordaram com os problemas levantados pelo artigo. Lembrando que esse artigo é apenas um trabalho em andamento, parte da minha dissertação de mestrado. Espero postar partes dela em breve.

Chris Agmen-Smith apresentou sua experiência em um projeto real com ATDD, e fez questão de mostrar que é possível fazer ATDD sem grandes custos, mas com muitos benefícios.

No final do dia, Raj Mudhar solicitou ajuda para pesquisar na área de ATDD em projetos de grande porte. Qualquer empresa que tenha projetos grandes pode participar, divulgando seus dados e juntos publicarem os resultados em conferências de peso.

Resumindo, o evento foi muito muito bom. Um dia inteiro com riquíssimas discussões sobre as mais variadas pesquisas em TDD. Além disso, pude validar muitas ideias com pessoas realmente influentes na área. Um ponto muito interessante é que não estamos tão longe do que eles praticam no dia-a-dia, mas ainda temos um longo caminho a percorrer!

Até a TDD2011, em Berlin!

Nos últimos anos, a comunidade acadêmica vem rodando diversos experimentos para tentar mostrar de maneira empírica que TDD realmente ajuda no processo de desenvolvimento de software. Alguns desses estudos são feitos por professores bastante conhecidos na comunidade, como a prof. Laurie Williams (North Carolina State University) e o prof. David Janzen (California Polytechnic State University).

Algumas dessas pesquisas investigam o fato de TDD reduzir o número de defeitos de um software; já outros investigam o fato de TDD produzir código de melhor qualidade. Alguns até pesquisam por indícios de aumento de produtividade.

Estudos na indústria

Janzen [5] mostrou que programadores usando TDD na indústria produziram código que passaram em aproximadamente 50% mais testes caixa-preta do que

o código produzido por grupos de controle que não usavam TDD. Além do mais, o grupo que usava TDD gastou menos tempo debugando. Janzen também mostrou que a complexidade dos algoritmos era muito menor e a quantidade e cobertura dos testes era maior nos códigos escritos com TDD.

Um estudo feito pelo Maximillien e Williams [6] mostrou uma redução de 40-50% na quantidade de defeitos e um impacto mínimo na produtividade quando programadores usaram TDD.

Outro estudo feito por Lui e Chan [7] comparando dois grupos, um utilizando TDD e o outro escrevendo testes apenas após a implementação, mostrou uma redução significante no número defeitos. Além do mais, os defeitos que foram encontrados eram corrigidos mais rapidamente pelo grupo que utilizou TDD. O estudo feito por Damm, Lundberg e Olson [8] também mostra uma redução significante nos defeitos.

O estudo feito por George e Williams[9] mostrou que, apesar de TDD poder reduzir inicialmente a produtividade dos desenvolvedores mais inexperientes, o código produzido passou entre 18% a 50% mais em testes caixa-preta do que códigos produzidos por grupos que não utilizavam TDD. Esse código também apresentou uma cobertura entre 92% a 98%. Uma análise qualitativa mostrou que 87.5% dos programadores acreditam que TDD facilitou o entendimentos dos requisitos e 95.8% acreditam que TDD reduziu o tempo gasto com debug. 78% também acreditam que TDD aumentou a produtividade da equipe. Entretanto, apenas 50% acreditam que TDD ajuda a diminuir o tempo de desenvolvimento. Sobre qualidade, 92% acreditam que TDD ajuda a manter um código de maior qualidade e 79% acreditam que ele promove um design mais simples.

Nagappan [12] mostrou um estudo de caso na Microsoft e na IBM e os resultados indicaram que o número de defeitos de quatro produtos diminuir entre 40% a 90% em relação à projetos similares que não usaram TDD. Entretanto, o estudo mostrou também TDD aumentou o tempo inicial de desenvolvimento entre 15% a 35%.

Langr [10] mostrou que TDD aumenta a qualidade código, provê uma facilidade maior de manutenção e ajuda a produzir 33% mais testes comparados a abordagens tradicionais.

Estudos na academia

Um estudo feito por Erdogmus et all [11] com 24 estudos de graduação mostrou que TDD aumenta a produtividade. Entretanto nenhuma diferença de qualidade no código foi encontrada.

Outro estudo feito por Janzen[13] com três diferentes grupos de alunos (cada um deles usando uma abordagem diferente: TDD, test-last, sem testes), mostrou que o código produzido pelo time que fez TDD usou melhor conceitos de orientação a objetos e as responsabilidades foram separadas em 13 diferentes classes enquanto que os outros times produziram um código mais procedural. O time de TDD também produziu mais código e entregou mais features. Os testes produzidos por esse time teve duas vezes mais asserções que os outros e cobriu 86% mais branches do que o time test-last. Além do mais, as classes testadas tinham valores de acoplamento 104% menor do que as classes não testadas e os métodos eram, na média, 43% menos complexos do que os não-testados.

O estudo de Müller e Hagner [17] mostrou que TDD não resulta em melhor qualidade ou produtividade. Entretanto, os estudantes perceberam um melhor reuso dos códigos produzidos com TDD.

Steinberg [15] mostrou que código produzido com TDD é mais coeso e menos acoplado. Os estudantes também reportaram que os defeitos eram mais fáceis de serem corrigidos.

O estudo do Edwards [16] com 59 estudantes mostrou que código produzido com TDD tem 45% menos defeitos e faz com que o programador se sinta mais a vontade com ele.

Conclusão

A maioria dos experimentos feitos tanto na indústria quanto na academia mostram que TDD melhora o processo de desenvolvimento de software, aumentando a qualidade do código, reduzindo o número de defeitos, diminuindo o tempo gasto com depuração e até aumentando a produtividade dos desenvolvedores.

Entretanto, mais experimentos devem ser conduzidos, levando em consideração diferentes fatores de influência que existem em um ambiente de desenvolvimento de software.

Referências

Podem ser encontradas aqui.

You can find the survey at http://spreadsheets.google.com/viewform?formkey=dFlITDZfSTNkVmd5bEVQSFl4cTB3cHc6MA

I also twitted about it (http://twitter.com/mauricioaniche/status/7493800359), so it would nice if you re-tweet!

A primeira palestra foi dada pelo Phillip Calçado, consultor da ThoughtWorks. “Tudo o que eu gostaria de saber antes de virar líder técnico” são um conjunto de dicas que ele aprendeu ao longo do tempo. Uma das lições foi sobre ENTREGAR VALOR o tempo todo, no momento exato e antes que fosse tarde demais! Outra lição interessante foi que IMPREVISTOS ACONTECEM, então ajude a evitá-los! Outras dicas importantes, como TDD, builds rápidos, integração contínua, criação de ambiente de testes parecido (o máximo possível) com o ambiente de produção, cliente sempre por perto, domain-driven design e entregas incrementais e frequentes foram citadas como “barreiras” para ajuda a evitar os imprevistos. Outra dica é para não se desesperar caso a barreira quebre (apenas garanta que você saiba quando ela quebrar). Ele disse uma frase que achei bastante interessante sobre isso: “Não é ser a prova de falhas, e sim tornar seguro falhar”.

A próxima palestra foi do Fábio Kung, sobre Cloud Computing. O Fábio parecia bem animado com o problema que tem em mãos! Foi bastante interessante, mostrando as possíveis diferentes classificações para uma cloud (IaaS, PaaS, SaaS). Explicou muito bem a diferença de cada uma delas, de maneira clara. Além disso mostrou dois vídeos engraçadíssimos sobre um tal de Dr. Cloud (ou algo assim)! Não peguei o link, assim que conseguir coloco aqui!

O lightning talk do Rafael Martinelli sobre Flex também foi bastante interessante. Mostrou vários exemplos de aplicações RIA feitos pela DClick, realmente impressionantes. Ele comentou também que RIA não é apenas “deixar bonito”; há um propósito por trás disso. Uma boa experiência do usuário traz mais retorno para a empresa.

A palestra sobre RESTful Web Services do Luiz Costa e do Sérgio Junior começou com eles contando uma história de uma aplicação que precisava se integrar com outras. E a partir dessa história, mostraram cada tentativa de integração até se chegar em web services. Quando chegaram em REST, explicaram bem as idéias e conceitos. Terminaram falando algumas das vantagens e desvantagens do uso de REST. Os slides estão em http://www.slideshare.net/sergiorjunior/rest-teoria-e-pratica

O Guilherme Silveira e o Filipe Sabella falaram sobre o novo VRaptor3, framework  MVC Java para Web, criado pela Caelum. Contaram a evolução do framerowk desde sua primeira versão em 2004 até agora. Mostraram como é fácil integrar o VRaptor com outros frameworks famosos no mercado como Spring, DWR, Flex. Uma característica interessante é que ele é refactor friendly (se você refatorar um método de um controller, não é necessário alterar XMLs para arrumar os redirecionamentos!). Você pode construir suas aplicações utilizando conceitos de REST também, de maneira fácil (basta utilizar algumas anotações e está pronto). Além de um monte de funcionalidades que já vem de graça com ele, como uploads e downloads de arquivos de maneira fácil, views em JSON, XML, e etc. Enfim, sugiro você avaliar o VRaptor como seu próximo framework para Web. (Ah, detalhe da palestra foi a foto do Filipe dormindo no sofá!).

O Cauê Guerra falou sobre “O Ano do Rails no Brasil”. Mostrou as diversas facilidades do desenvolvimento Rails e mostrou uma série de empresas que já o utilizam. E pra quem pensa que só empresas pequenas usam, ele mostrou uma lista de empresas de grande porte que já utilizam Rails em algumas de suas aplicações! No final, mostrou que já existem boas vagas para profissionais Rails (detalhe para a foto das meninas procurando por Railers!). Os slides da palestra dele estão em http://www.slideshare.net/caueguerra/2009-o-ano-do-ruby-on-rails-no-brasil-caelumday-2009.

O lightning talk do Paulo Silveira sobre Persistência Java foi bastante interessante. Ele mostrou a evolução do processo de persistência de dados em Java, indo desde a conexão direta com o banco até JP, discutindo os prós e contras de cada abordagem. Muito legal o link que ele fez no final com todas as outras palestras do evento.

A última palestra entitulada NoSQL (Not Only SQL) do Nico Steppat comentou sobre banco de dados não-relacionais. Mostrou como é realmente difícil escalar bancos de dados relacionais, comentou sobre banco de dados como CouchDB, Project Voldemort, Bigtable, e etc,  e discutiu sobre técnicas que eles usam para distribuir. Mostrou que conseguimos controlar apenas dois elementos desses três: Consistência, Disponibilidade e Tolerância à Partição (Brewer, 2000). E cada um deve fazer sua escolha dependendo da sua necessidade.

O evento acabou aí, e eu tive que correr pro aeroporto, pois meu avião saia do Galeão! Resumindo, o evento foi muito bom e valeu muito a pena! Espero ir de novo ano que vem!

Por fim, gostaria de agradecer ao Paulo Silveira pelo convite!

O evento acontecerá dentro da Universidade de São Paulo (USP). Os dias 10 e 11 de outubro estão reservados para discussões, trocas de experiências e palestras de especialistas em Programação eXtrema, Scrum, Crystal e nas metodologias mais produtivas do mercado.

Conheça os profissionais que já usam métodos ágeis. Junte-se ao grupo que está revolucionando a maneira de produzir software. Participe das discussões mais atuais do mercado, tire suas dúvidas e descubra como as técnicas ágeis podem ajudá-lo a aumentar a produtividade da sua equipe e a qualidade do seu software.

Este ano, nossos convidados especiais são Jutta Eckstein e Joe Yoder, que ministrarão keynotes e tutoriais durante o evento.

Mais informações em http://www.encontroagil.com.br

Espero vocês lá!

Eu ia pular a questão inicial, mas vou revisar para que facilite o entendimento do resto do post para quem não leu os links acima. Uma entidade pode conhecer/utilizar um repositório? Acho que a resposta é óbvia: Sim. Repositórios são conceitos de negócios, fazem parte do domínio, e por isso não há nada de errado em uma entidade conhecer um repositório. Não vou entrar no mérito de como o repositório deve ser implementado, não é o meu interesse no momento. Mas vamos lá… Ok, podemos ter entidades que dependem de um repositório, e o problema é: como gerenciar essa dependência?

A seguir, discutimos algumas abordagens para resolver esse problema e chegamos em algumas conclusões, das quais gostaria de compartilhar.

Sugestão I: Receber o repositório pelo construtor
A entidade deve possuir um construtor que receba a dependência.

Vantagens:

• A dependência fica explícita, ou seja, não há como criar uma entidade sem entregar a dependência já resolvida.

Problemas:

• Torna o código menos legível, afinal sempre que for instanciar uma entidade, deve-se injetar seu repositório.
  Ex: Pessoa mauricio = new Pessoa ( repositorioDePessoas );
• Imagine uma entidade que depende de mais de um repositório (por quê não?). Imagine passar os diversos repositórios no construtor. Menos legível ainda…
  Ex: Pessoa mauricio = new Pessoa ( repositorioDePessoas, repositorioDeXPTO, repositorioDeXYZ );
• Isso fica pior ainda quando definimos um construtor que receba algum atributo, por exemplo.
• Ex: Pessoa mauricio = new Pessoa ( “mauricio”, “aniche”, repositorioDePessoas, repositorioDeXPTO );

Testabilidade:

• É fácil injetar um mock no lugar da dependência, para facilitar o teste unitário da entidade.

Sugestão II: Definir um setter para a dependência
A entidade deve ter um método setDependencia() que receba a dependência.

Vantagens:

• Elimina o problema de resolver a dependência no momento da criação do objeto.

Problemas:

• Você precisa setar a dependência sempre que for utilizar, e isso pode ser um problema. Você precisará fazer todo o tempo algum tipo de validação no código da entidade para saber se a dependência já foi injetada ou não.
  Ex: public List<XPTO> pegaXpto(int abc) { if(repositorio!=null) repositorio.pegaX(abc); }

Testabilidade:

• Também é fácil injetar um mock no lugar da dependência.

Sugestão III: Utilizar o próprio repositório para injetar repositórios nas entidades
Conforme sugerido pelo Paulo Silveira e pelo Fabio Kung no post, sempre que um objeto for recuperado pelo seu repositório, o mesmo deve se “auto-injetar” antes de devolver o objeto.

Vantagens:

• A complexidade do gerenciamento desse dependência fica escondida no código do repositório.
• O código a ser implementado, de maneira geral, é simples.

Problemas:

• Apesar de ser simples, deve ser replicado em todos os métodos do repositório. Se o método do repositório retornar uma lista, por exemplo, deve-se repetir o processo em todos os elementos dessa lista.
• Apenas as entidades que são recuperadas pelo repositório recebem a dependência. Entidades criadas em qualquer outro ponto do projeto não recebem essa dependência de forma automática. Isso pode causar o problema levantado na sugestão II.
• Caso a entidade mude e venha a depender de um outro repositório, você terá muito código para alterar.

Testabilidade:

• Da mesma maneira que o repositório injeta a dependência (através de um setter), pode-se injetar um mock.

Sugestão IV: Injetar o repositório por AOP
Uma idéia bastante interessante seria injetar a dependência por AOP. Dessa maneira não importaria como o bean é instanciado, seja ele feito pelo JPA, Hibernate, etc, ou pelo programador. Essa foi uma sugestão levantada pelo Alessandro Lazarotti, nesse post do GUJ.

Vantagens:

• O código fica bastante claro.

Problemas:

• A implementação de um aspecto geralmente não é trivial.

Testabilidade:

• Dependendo do modo que o aspecto for implementado, talvez não seja tão trivial injetar a dependência. Para facilitar, pode-se criar um setter exclusivamente para isso, mas não é muito elegante.

Sugestão V: Resolver a dependência dentro da própria entidade
A idéia seria a própria entidade resolver a sua dependência. No caso, ela mesma invocaria o framework de DI, e recuperaria a instância da dependência. Pode-se até pensar em uma Factory para que a entidade não dependesse diretamente de uma implementação de framework de DI.

Vantagens:

• Solução bastante simples.
• Acaba com o problema da necessidade da entidade validar se a dependência foi injetada ou não, já que ela mesma vai resolver.

Problemas:

• Não é muito elegante fazer com que a própria classe resolva suas dependências.

Testabilidade:

• Como é a própria classe que resolve a dependência, você precisará de um setter para conseguir injetar um mock. Como dito acima, não é muito legal.

(*) Além do que foi citado acima, existe um outro problema, ortogonal ao das dependências, e diz respeito diretamente à implementação desse projeto em particular. Por estarmos discutindo uma aplicação web, o contexto do Spring está guardado dentro do contexto web. Para que um POJO qualquer recupere esse contexto, ele precisaria conhecer o servletContext. Ainda não encontrei uma maneira muito clara para resolver isso, mas minha sugestão é criar uma classe singleton que conteria um atributo com uma instância de contexto do Spring, e essa instância seria injetada por um filter ou um listener qualquer, que subiria logo após ao listener do Spring. A partir daí, todas as classes de domínio fariam acesso à esse singleton para capturar o contexto.

Portanto, é possível gerenciar essa dependência de diversas formas, todas elas com suas vantagens e desvantagens. E você, como faz?