Aprenda C
Meu primeiro computador foi um TK85. Nele eu aprendi o BASIC e comecei a programar. Logo eu percebi que o BASIC não era suficiente para fazer tudo o que queria e comecei a estudar Assembly Z80. Nessa época não tinha internet, a gente aprendia muitas coisas nos livros e revistas, mas na maioria do tempo era por tentativa e erro. Todas essas dificuldades e limitações ajudaram a formar uma geração que conhece muito bem como um computador funciona e sabe muito bem como programar. Hoje em dia, o cara que quer começar na área já começa aprendendo uma linguagem como Java, PHP, C#, Ruby, ou sei lá o que e se tornam engenheiros medíocres... Falta uma base sólida! A maioria dos engenheiros hoje em dia não têem a mínima idéia de como as linguagens e os computadores funcionam. Se você está começando, aprenda C (não precisa ser assembly). Aprendendo e usando C, você vai construir a base de conhecimentos necessária para ser tornar um bom engenheiro. Depois de ter essa base, você vai aprender qualquer linguagem com muita facilidade, se tornando um excelente programador.
DbUnit x Hibernate
Aqui na empresa, temos clientes que apenas mandam executar um projeto segundo a arquitetura definida por eles. Algumas vezes é frustante trabalhar neste tipo de projeto, afinal, nem sempre conseguimos seguir nossas convicções e utilizar plenamente nossos conhecimentos e experiência na definição da melhor solução para o problema. Em um desses projetos, fui convocado para auxiliar a equipe que estava consumindo muito tempo na implementação dos testes.
O Cenário:
O sistema utiliza EJB 2 e Hibernate 2. O cliente exige implementação de testes dos métodos da fachada utilizando JUnit e DbUnit.
Problemas:
A montagem dos cenários é complexa. O DbUnit entende apenas o modelo relacional, isto significa que o engenheiro tem que fazer um "desmapeamento hibernate" na cabeça dele para montar as tabelas e colunas com os valores necessários. Veja um exemplo:
<dataset>
<employee start_date="2001-01-01"
first_name="Drew"
ssn="333-29-9999"
last_name="Smith" />
<employee start_date="2002-04-04"
first_name="Nick"
ssn="222-90-1111"
last_name="Marquiss" />
<employee start_date="2003-06-03"
first_name="Jose"
ssn="111-67-2222"
last_name="Whitson" />
</dataset>
Claro que esse é um modelo relacional simples, agora imagine modelos de classes complexos, com heranças, relacionamentos, etc. Neste caso, dá bastante trabalho.
Além da dificuldade em produzir a massa de dados, existe um problema muito grave. Dentro das classes de teste é necessário fazer validações contra os valores do arquivo xml (por exemplo em métodos de consulta). Neste caso podemos fazer as validações com valores hard coded, como neste exemplo:
assertEquals(employee.getFirstName(), "Jose");
Que é uma péssima idéia, pois viola o princípio DRY (Don't Repeat Yourself). Outra saída é obter os valores do xml através da API do DbUnit, que vai dar uma trabalheira danada, ainda mais se você quiser montar o objeto para fazer comparações deste tipo:
assertEquals(employeeActual, employeeExpected);
Já imaginou? Vai ter que construir outro hibernate só para pegar cada valor das tabelas e colunas do arquivo XML e remontar os objetos novamente.
Como Resolver?
O grande problema dessa abordagem é o fato do DbUnit entender apenas de tabelas e colunas. E se existisse um HibernateUnit? No hipotético HibernateUnit eu poderia especificar meus dados na forma de objetos. Além disso, poderia utilizar um formato mais legível e que pudesse ser transformado diretamente para objetos dentro do seu código. Esse formato pode ser o YAML. Veja como ficaria:
- &engineering
id : 1
name : Engineering
employees:
- id : 1
startDate : 2001-01-01
firstName : Drew
lastName : Smith
ssn : 333-29-9999
departament : *engineering
- id : 2
startDate : 2002-04-04
firstName : Nick
lastName : Marquiss
ssn : 222-90-1111
departament : *engineering
- id : 3
startDate : 2003-06-03
firstName : Jose
lastName : Whitson
ssn : 111-67-2222
departament : *engineering
Inclui um relacionamento para employee só para ficar um pouco mais rico. A vantagem dessa abordagem é que além de ficar mais legível, existem frameworks que serializam e deserializam esse formato para objetos. Com esse recurso, seria possível obter os objetos diretamente do arquivo e em seguida fazer comparações com objetos obtidos no banco. Legal, hein?
Acho que uma solução deste tipo poderia trazer muitos benefícios para o nosso problema. Estou fazendo uma pesquisa e se não existir nada semelhante, devo implementar essa solução como um projeto open source.
Pena que nosso cliente EXIGE que usemos o DbUnit.
Apresentação
Meu nome é Luiz Borba, sou formado em Ciência da Computação pela UFPE e trabalho com desenvolvimento de software desde 1991. Apesar de ter um forte background técnico, me interesso por todos os aspectos desta atividade. Hoje em dia trabalho em uma grande empresa em Recife, onde sou responsável por dar suporte a todos os times em arquitetura, produtividade e qualidade de código.
Minha intenção ao criar este blog é compartilhar minha experiência e minhas idéias sobre desenvolvimento de software, criando um ambiente para discutir sobre este assunto com outras pessoas da área e consequentemente aprender mais...
Espero que vocês gostem e me ajudem. 