Protótipo de JavaEE Beans sem zombar

Eu não escrevo testes de integração para código de banco de dados (DAOs) porque é uma perda de tempo. Você vai conectar alguns dados com os quais o código deve funcionar e, em seguida, testá-los. Quando o esquema muda e você está executando com os dados errados, seu teste perde o sentido.

É aqui que entram os testes de integração – o ponto é que você está executando em um banco de dados real (espero que não em um banco de dados de produção ..) e pode testar tudo de verdade. Mas configurar isso é um pé no saco, sem mencionar que se você está realmente tentando fazer um protótipo de algo, ou apenas experimentar algum novo método DAO, é muito mais conveniente executar seu código em um ambiente real.

Primeiro, escrevo uma classe que será com @Startup em @PostConstruct. Em seguida, inicie-o com um depurador e observe-o ir.

@Singleton
@Startup
public class SomeSandbox {

@EJB
SomeBean b;

@PostConstruct
public void init() {

// loop until the function is doing what I want
boolean rerun = true;
do {
doSomething
();
} while(rerun);
// unset rerun in the debugger and test the function out for real
}

private void doSomething() {
// do something with bean
}
}

O que isso me permite fazer é definir um ponto de interrupção em doSomething () e ajustar o método até que ele faça o que desejo. Então, em meu depurador, defini reexecutar como false, o aplicativo continua com seu dia, dando-me a chance de experimentar meu novo código de verdade. Quando termino, excluo meu código de sandbox e escrevo um teste sólido que é o mais à prova de futuro possível.

É simples, eficaz e me permite testar o código do ecossistema em que será executado, em vez de zombar de algo inteiramente.

A desvantagem desse método é que você ainda precisa escrever seu teste de integração depois, mas eu prefiro esse método de qualquer maneira. Não sou um grande fã de “escrever um teste e vê-lo falhar até que ele seja aprovado”, especialmente ao fazer algo em um banco de dados.