Olá
Sabemos que nem todas as aplicações que mantemos usufruem de um modelo de domínio rico. Muitas delas utilizam objetos burros e inserem as regras de negócio em serviços que usam esses objetos. E muitos desses serviços não incluem apenas a lógica de negócio: geralmente embutem outros aspectos do sistema, como infraestrutura e logging.
Vale a pena inserir testes nesse contexto? Como vocês tem aplicado testes nessa arquitetura em particular?
É impossivel mudar o cenario?
Não digo da noite pro dia, mas aos poucos. Quando voce tem que alterar um determinado ponto da aplicacao, voce pode refatorar, melhorar o dominio, incluindo testes.
Nao vejo vantagens em por testes num sistema monolitico, sem melhorá-lo. Muito trabalho e pouco resultado.
Se voce nao conhece eu recomendo:
Ótima recomendação de livro, Paulo. Não o conhecia, obrigado.
Mudar o cenário? Hmmm… Eu diria que é preciso mudá-lo de qualquer jeito, independente de mantermos o transaction script ou mudarmos para domain model. Os serviços precisam ser refatorados para cuidar apenas de regras de negócio, e delegar as outras responsabilidades - persistência, logging - para serviços externos. Senão nunca teremos testes que testem apenas as regras de negócio.
Mas eu gostaria de saber se alguém aqui já teve a experiência de escrever testes para um transaction script.
[quote=tnaires]Ótima recomendação de livro, Paulo. Não o conhecia, obrigado.
Mudar o cenário? Hmmm… Eu diria que é preciso mudá-lo de qualquer jeito, independente de mantermos o transaction script ou mudarmos para domain model. Os serviços precisam ser refatorados para cuidar apenas de regras de negócio, e delegar as outras responsabilidades - persistência, logging - para serviços externos. Senão nunca teremos testes que testem apenas as regras de negócio.
Mas eu gostaria de saber se alguém aqui já teve a experiência de escrever testes para um transaction script.[/quote]
Entao, nao sei se eh exatamente o que voce pergunta, mas quando eu ouco Transaction Script, pela definicao do PoEAA, me vem a cabeca, algo pequeno, que nao precisa de um dominio rico, mas que é organizado. Nao parece ser esse o seu caso.
Se com Transaction Script voce quer dizer aquela massaroca desgraçada que a gente encontra todos dias, nesse caso sim, já tive experiencia e ainda lido com eles.
Pode ser que alguem lhe de melhores noticias, mas no meu caso foi aquilo q eu te falei. A medida que preciso mexer vou retatorando e pondo testes, esse livro ajuda bastante na forma de fazer as alteracoes, encontrar os pontos e alterar, mas o resultado demora, nao aparece da noite pro dia e nem é tao divertido quanto usar TDD desde o inicio do projeto.
[quote=YvGa]Entao, nao sei se eh exatamente o que voce pergunta, mas quando eu ouco Transaction Script, pela definicao do PoEAA, me vem a cabeca, algo pequeno, que nao precisa de um dominio rico, mas que é organizado. Nao parece ser esse o seu caso.
Se com Transaction Script voce quer dizer aquela massaroca desgraçada que a gente encontra todos dias, nesse caso sim, já tive experiencia e ainda lido com eles.[/quote]
Aí é que está, o Transaction Script deve ser usado para aplicações simples. Quando é utilizada para aplicações com domínio um pouco mais complexos que um CRUD, fica uma porcaria… Some a isso o fato de que todos os serviços não estão desacoplados das ortogonalidades - persistência, logging…
Então você procura refatorar para um domain model ou mantém a arquitetura original?
Tento refatorar, mas nao forço. Nao sou muito fã da opção de refazer tudo, a nao ser que nao esteja funcionando mesmo ou nao esteja em producao.
Eh muito arriscado mexer em algo que nao tem testes e esta em producao, o que eu venho fazendo eh refatorar e incluir testes a medida que preciso alterar qualquer funcionalidade. Eh um processo que leva tempo, o resultado eh lento, mas eu procuro ir caminhando para um domain model sim.
O que eu aconselho tambem eh ter sempre o Refactoring e o Working effetively with legacy code sempre a mao.