Testar métodos em classes abstratas

[Arthur Cláudio Almeida Pereira]

Fala Pessoal!

  Tenho uma classe abstrata com um método em comum para diversas classes.  

  Sei que posso instanciar uma das classes concretas e testar mas assim não fica um pouco obscuro? Digo isso porquê o teste ficaria específico na classe de teste de uma das classes concretas e assim não acho que fica expressivo.

  Parece que estou testando algum comportamento daquela classe ao invés de testar um comportamento compartilhado ( da classe abstrata) entre todas.

  O que vocês costumam fazer nesse momento?

[Alexandre Leite]

Não sei se não entendi algo direito e posso estar falando uma bobagem, mas para mim parece óbvio que devemos criar uma subclasse da classe abstrata, que servirá como uma espécie de mock ou stub (mas sem sobrescrever o método em teste), e testar o método comum chamando a subclasse. Que tal?

Alexandre Leite

--
Você está recebendo esta mensagem porque se inscreveu no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Arthur Cláudio Almeida Pereira]

Entendeu certinho mesmo. Pois é. Acabei de ter essa idéia tbm. Estou implementando para ver no que dá!

[Mauricio Aniche]

Oi Arthur,

Acho que não tem muito como fugir disso mesmo. É criar uma classe
filha e testá-la.

Uma situação análoga a essa aparece quando você cria algum tipo de
infraestrutura que lida com anotações. Pra testar, você precisar criar
uma classe que contenha essas anotações e ver que você as processa
corretamente.

Soa como uma gambiarra, mas é o jeito, certo!? :)

Alguém tem alguma ideia melhor?

Um abraço,

--
Mauricio Aniche
www.caelum.com.br
www.TDDNoMundoReal.com.br
www.aniche.com.br
@mauricioaniche


2013/7/11 Arthur Cláudio Almeida Pereira <arthur.alm...@gmail.com>:

[Arthur Cláudio Almeida Pereira]

Agora só por uma questão de organização mesmo. Nesse caso vocês criariam um teste chamado AbstractTest  mesmo que no teste os asserts sejam em cima de uma classe filha criada somente para testar esses comportamentos genéricos ou chamaria de FilhaTest
?

[Wilson Batista da Silva Junior]

Oi Arthur.

E se no teste você criar um objeto a partir de uma classe anônima? Nos métodos abstratos você implementa qualquer coisa ou lança uma exceção. Vou exemplificar:

public abstract class Pessoa {
    private String nome;
    private String sobrenome;

    public Pessoa(String nome, String sobrenome) {
        this.nome = nome;
        this.sobrenome = sobrenome;
    }

    public String getNomeCompleto() {
        return nome + " " + sobrenome;
    }

    public abstract void facaAlgumaCoisa();
}

---

import static org.junit.Assert.assertEquals;

import org.junit.*;

public class PessoaTest {
    private Pessoa fulano;

    @Before
    public void setUp() throws Exception {
        fulano = new Pessoa("Fulano", "de Tal") {
            @Override
            public void facaAlgumaCoisa() {
                throw new RuntimeException(); // uma exeção mais especifica seria melhor. não consegui me lembrar de nenhuma
            }
        };
    }

    @Test
    public void nomeCompletoDeveSerFulano_de_TalTest() {
        assertEquals("Fulano de Tal", fulano.getNomeCompleto());
    }

    // mais testes
}

Nunca testei classes Abstratas. Pensei nessa abordagem depois do seu questionamento.

E, talvez, numa classe com muitos métodos abstratos essa abordagem não seja viável.

Abraço.

Junior.

[Alexandre Leite]

Eu nomearia o teste em função da classe abstrata. A classe filha seria inner ou na pasta dos testes.

Alexandre Leite

Enviado do celular.

[Mauricio Aniche]

Eu também daria o nome em cima da classe abstrata que está sendo
testada. Acho que fica mais natural. Do meu ponto de vista, as classes
filhas que você cria são como o "cenário" do seu teste!

Um abraço,
--
Mauricio Aniche
www.caelum.com.br
www.TDDNoMundoReal.com.br
www.aniche.com.br
@mauricioaniche

2013/7/12 Alexandre Leite <acl...@gmail.com>: