Agilidade do Spring com JavaEE

Venho estudando e trabalhando com JavaEE há algum tempo e já entendi bem as vantagens de trabalhar com a especificação.
Utilizo o Wildfly, trouxe pra empresa em que trabalho e onde encabeço projetos com JavaEE + Wildfly e Arquillain pra criar testes de integração.
Em determinado momento, me deparei com a seguinte situação, criar testes está muito difícil, está sendo uma situação custosa, cara, complicada, complexa, demorada… a produtividade diminuiu bastante no quesito testar código. Então, me peguei pesquisando sobre como solucionar esse problema. Me peguei lendo sobre Spring, acabei me interessando, conheci o Spring boot e achei bastante interessante.
Pra subir minha aplicação com o Wildfly, preciso baixar o servidor de aplicação, configurar o datasource, configurar os módulos dos drivers jdbc, baixar os drivers, configurar loggs… uma parafernalha de coisas que pra subir o ambiente de produção é uma complicação, isso se reflete também no ambiente de desenvolvimento.
Achei a facilidade do Spring absurda, fiquei até meio zonzo sem conseguir entender, mas entendi a ideia e consegui acreditar.
Pensei na seguinte situação, “PUTS… VOU TER QUE VOLTAR ATRÁS E COMEÇAR O PROJETO COM SPRING”, mas achei a ideia nada interessante, a equipe já está grande, está trabalhando muito bem com as tecnologias que já utilizamos… Minha pergunta é, existe a possibilidade de ter a mesma agilidade com o JavaEE? Consigo ter um ambiente tão simples de se trabalhar como temos com o Spring Boot no JavaEE?

Criar testes não é uma tarefa simples, é parte fundamental do processo de desenvolvimento. Porém, a não ser que você tenha uma fábrica de software, você não cria testes toda hora. O máximo que faz é adequar os testes já criados e/ou criar novos testes para casos que não haviam sido contemplados anteriormente.
A questão é: qual abordagem vocês estão seguindo? TDD? BDD? DDD? Nenhuma? Qual a maturidade da equipe em relação a testes unitários e integrados (o mínimo que se espera)?

Essa descrição de ter que parar o AS parece mais com a maneira de usar Apache Tomcat, exceto pelo fato de que as configurações não se perdem.
Para subir a aplicação você realmente precisa terr tudo configurado, mas, não tem necessidade de baixar o servidor de aplicação. No máximo, você vai baixar um nó (caso esteja trabalhando em cluster) ou diretamente a aplicação, afinal, uma nova versão só pode rodar se a antiga for removida do AS.
Eu não sei de que forma você está fazendo isso, mas, todas as vezes que usei wildfly (e o JBoss que o precedia), eu nunca precisei reconfigurar nada, nem baixar o AS. Apenas configurava uma vez e as demais eu só mexia quando fosse alterado algo.

O que me parece é um mau uso das ferramentas. Talvez fosse importante entender como o Wildfly realmente trabalha e as melhores práticas para trabalhar com ele.

1 curtida

Apenas para dar um contraponto: o Spring é imensamente mais produtivo, mais fácil e menos chato. Porém, como qualquer framework, ele tem um bom suporte ao que é corriqueiro (crud simples, por exemplo).
A partir do momento que você precisa de coisas mais específicas, isso pode se tornar uma via de duas mãos: a boa, pela parte “comum” e a ruim, pelas necessidades específicas.
Então, é bem comum você encontrar projetos Spring com Spring Boot + Spring Data em que não se usam os melhores recursos do Spring Data em sua totalidade. Ao invés disso, cria-se aquelas monstruosas native queries.
Esse é só um exemplo, mas, tem várias atrocidades que são feitas em prol do desenvolvimento rápido em detrimento das boas práticas e do aprendizado.

Particularmente eu não vejo muito futuro para o JavaEE depois do advento de containers (leia-se Docker e Kubernetes). De qualquer maneira, essa dificuldade de se criar testes automatizados me parece mais um sintoma do acoplamento da regra de negócio com o banco do que um problema de infra-estrutura em si. Testes de integração automatizados são caros mesmo, seja utilizando JavaEE ou Spring.

Ainda se fala em Java EE/Jakarta EE? Esquece isso para sistemas novos em Java.

Se o cliente de voces é quem diretamente usa o sistema, prefira testes funcionais com Selenium. Nesse cenário, qualquer outro tipo teste fica longe da realidade, não valendo o investimento, que é alto mesmo em qualquer tipo de teste. Tem que ter alguem dedicado pra isso, geralmente analistas de qualidade.