ABAP da SAP tem uma interface para testes unitários
Eu e o @frmarcio testamos um pouco do ABAPUnit e tivemos uma ideia do que ele pode trazer para a melhoria da qualidade do que estamos implementando.
Para melhor entender todo o processo, resolvemos usar TDD para guiar o nosso desenvolvimento e usamos o exemplo do Jogo Papel x Tesoura x Pedra tirado do site Abap101.
A primeiro impressão foi ótima, é muito parecido com o JUnit do Java, com as mesmas ideias e conceitos, simplificando o entendimento. Tem apenas 1 limitação que atrapalhou um pouco: O tamanho máximo dos métodos é de apenas 30 caracteres. Atrapalha um pouco, mas não inviabiliza.
A classe é criada automaticamente com dois métodos:
- Setup – ajustar o ambiente antes de executar o teste.
- Teardown – voltar o ambiente ao estado anterior após o teste
Levamos 3 pomodoros (ou seja, 1:30) para realizar o exercício. A maior dificuldade mesmo foi entender o funcionamento da Orientação a Objetos do ABAP, ultrapassando essa barreira, o trabalho fluiu muito bem.
No final, conversamos o que achamos de interessante e o que tínhamos aprendido. Constatamos o que já sabíamos: Programar orientado a testes é uma mudança de cultura. Por outro lado, dá muita segurança para quem está desenvolvendo. Comentamos entre nós: Se tivéssemos esse código fonte (foi aproximadamente 50 linhas) sem testes teríamos a segurança que estamos tendo agora? A resposta foi rápida: Não. O TDD dá uma segurança muito boa, inclusive realizamos refatoração durante o exercício com total segurança.
Outra coisa que conversamos é sobre os códigos fontes legados, o que fazer? Minha opinião é que não devemos nos preocupar por enquanto com isso, devemos nos preocupar com o que vamos fazer daqui para diante.
Sabemos que para alavancar esse processo é uma mudança cultural, mas acho que um bom ponto de partida foram as conclusões de vocês referente ao valor/qualidade que isso traz para a equipe. Ter o “aceite” de quem está executando a tarefa é primordial, pois fazer algo que não acreditamos que vai dar certo torna-se mais difícil de colocar em prática.
Também acho que para iniciar podemos começar com iniciativas novas. Se os resultados forem bons, mais adiante podemos reavaliar o código legado.
E não sei se a mudança maior é no caso ocasionada pelo TDD, acho que é ocasionada mais pela Orientação a Objetos, como ter métodos específicos, que façam operações específicas ao invés de grandes programas procedurais que fazem muita coisa. Que até então, é mudar para melhor.
Depois disso, o TDD fica fácil
Acho que uma mudança para cultura de orientação a objetos é ainda mais radical que a mudança de cultura causada pelo TDD. Especialmente quando temos um mercado SAP com poucos desenvolvedores com background em ciência da computação. O bom é que internamente não temos este problema e podemos contar com pessoas muito bem capacitadas.
A grande mudança mesmo é pensar nos tamanhos do que tu fazendo e deixar de um tamanho que seja testável. É muito mais dificil imaginar casos de testes para algo que tenha 2 mil linhas contra algo que tenha 100 ou 200 linhas. Essa é a maior mudança que precisa ser realizada, pensar em módulos menores para facilitar os testes
Olá peixotmarc!
Sou autor do ABAP101, juntamente com o Furlan. Fui o criador do post e do exercício que você fez. Fico muito feliz de saber que ele lhe foi útil.
Desculpe-me, mas não havia visto este post antes pois o wordpress o marcou como spam. Estávamos dando uma olhada neles e percebemos esta citação.
A propósito… poderia me passar seu contato?
Obrigado,