Herança é um dos termos mais discutidos em orientação a objetos. Há uma discussão antiga sobre as vantagens e desvantagens com relação à Composição. Em outro artigo, o Aniche trouxe o Príncipio da Substituição de Liskov. Além disso, uma outra discussão famosa e bem antiga é a possibilidade de DAOs genéricos. Por fim, também cito o uso da herança para lidar com chain of resposibility e o excelente Joshua Bloch.

Por: Raphael Lacerda

Como podemos ver, a discussão é longa e o questionamento que eu trago é: como lidar com herança e testes de unidade?

Bom, para entender o post, além de Herança, você deve estar familiarizado com a importância de se fazer testes automatizados. Principalmente os testes de unidade, que é basicamente o foco do artigo. A ideia aqui é ver o quanto que o teste pode te ajudar a descobrir problemas de design no seu código.

No cenário proposto, se você tivesse controle sobre este código, provavelmente iria preferir utilizar a composição para resolver o problema, devido aos motivos já relatados no primeiro parágrafo. Todavia, vamos partir da premissa que seja necessário o uso de uma API de um terceiro e a herança é obrigatória. Como lidar com os testes? Vamos ao código!

//classe do Fabricante
abstract class AbstractService {
public Service getService() {
//faz algo que vc não tem controle consultar um WS, REST, BD,etc.
}
}

class ServicoDeNotaFiscal extends AbstractService {
private NotaFiscal notaFiscal = new NotaFiscal();

public void run(){

Service service = getService();

if(service.isOperationInitialized()){

notaFiscal.mudarParaEstado(Estado.CRIADA);
}else{

notaFiscal.mudarParaEstado(Estado.SUSPENSA);
}
}
}

class ServicoDeNotaFiscalTest{
private ServicoNotaFiscal servicoNotaFiscal;

@Before
public void init(){
servicoNotaFiscal = new ServicoNotaFiscal();
}

@Test
public void quandoOperacaoForIniciadaDeveColocarNotaFiscalComoCriada(){

servicoNotaFiscal.run();
assertEquals(Estado.CRIADA, servicoNotaFiscal.getNotaFiscal().getEstado());
}
}

Frameworks podem ajudar…

Ao rodar os testes, os stubs serão executados ao invés da implementação real. O teste passa, porém é uma solução mais prolixa. Você poderia usar o conceito de SPY Object (já explicado anteriormente –> “objeto real até que prove o contrário“) e um mock para Service.

“When you’re doing testing like this, you’re focusing on one element of the software at a time -hence the common term unit testing. The problem is that to make a single unit work, you often need other units”

class ServicoDeNotaFiscalTest{
@Spy
private ServicoNotaFiscal servicoNotaFiscal;
@Mock
private Service service;

@Before
public void init(){

when(service.isOperationIniatilized()).thenReturn(true));
doReturn(service).when(servicoNotaFiscal).getService();
}
}

Só piorar um pouquinho…

Particularmente acho que o código fica mais limpo e fácil de entender. Contudo, você pode encontrar um cenário mais desafiador: se o método getService for final.

abstract class AbstractService{
public final Service getService(){}
}

Agora a herança começa realmente a cobrar o seu acoplamento. Perceba que pelo método herdado ser final, não poderemos mais fazer os stubs. Além disso, o próprio spy do Mockito não funcionaria:

“Watch out for final methods. Mockito doesn’t mock final methods so the bottom line is: when you spy on real objects + you try to stub a final method = trouble. Also you won’t be able to verify those method as well.”

A solução aqui é quebrar um pouco o encapsulamento e extrair a chamada do getService para um método com visibilidade default. Depois, usaremos o Spy object para redefinir o comportamento deste novo método criado.

class ServicoDeNotaFiscal extends AbstractService {
public void run(){
Service service = buscarPorServico();
//mais código aqui
}

Service buscarPorServico(){
return getService();
}
}

class ServicoDeNotaFiscalTest{
@Spy
private ServicoNotaFiscal servicoNotaFiscal;
@Mock
private Service service;

@Before
public void init(){
doReturn(service).when(servicoNotaFiscal).buscarPorServico();
}
}

Concluindo, a atividade de automatizar os testes envolve uma série de desafios e herança é apenas um deles. No cenário citado, se ao invés de herdar de AbstractService ele recebesse como Injenção de Dependêcia um Service, seria muito mais fácil testar, inclusive mais fácil ver a sua consistência. Por isso que “há uma grande sinergia entre um bom design e testes automatizados” (Michael Feathers). Estes não vão fazer sua aplicação ter um bom Design da noite pro dia, entretanto a prática irá apontar os caminhos para melhorar.

Fonte: Caelum

Texto original:
blog.caelum.com.br/heranca-e-testes-unidade/