Sydney, que ótimo que você está querendo aprender testes. É uma coisa que realmente faz a diferença! Continue assim.
Mas aceita algumas críticas construtivas?
Espero que sim :)
Esse seu TestCase não está testando absolutamente nada. Não tem nenhum cenário definido e ainda por cima depende de intervenção humana, além de utilizar interface gráfica.
Um teste unitário deve possuir algumas premissas. Uma delas é a rapidez de execução e outra é a automatização. Existem também algumas boas práticas de testes, por exemplo, de ter pelo menos 1 assert por teste. Mas isso tu já deve ter lido por aí.
Vou dar um exemplo de teste de Login com senha.
1- Essa é a nossa interface de DAO de usuários:
public interface UserDAO {
public User getUserByUsernameAndPassword(String username, String password);
}
2- Essa é a nossa classe de Login
public class Login {
private UserDAO dao;
public boolean checkCredentials(String username, String password) {
return dao.getUserByUsernameAndPassword(username, password) != null;
}
public voit setUserDAO(UserDAO dao) {
this.dao = dao;
}
}
3- E esse é o nosso Stub. É um DAO "fake", usado especialmente em testes unitários. Ele vai simular uma situação bem específica, ou seja, vou simular um banco de dados que está gravado em um map
public class UserDAOStub implements UserDAO {
private Map<String, User> users = new HashMap<String, User>();
public UserDAOStub() {
users.put("teste", new User("Teste");
}
public boolean checkCredentials(String username, String password) {
return users.get(username) != null;
}
}
agora vou fazer o nosso TestCase. Vou fazer dois testes: Um que vou passar o usuário Teste e ele tem que logar e outro usuário que ele NAO PODE deixar logar. Vamos chamar de "mario"
public LoginTest extends TestCase {
public void test_login_com_sucesso() {
UserDAO dao = new UserDAOStub(); //criando o nosso stub
Login login = new Login();
login.setUserDAO(dao); // setamos o login para usar o DAO fake
String usuario = "teste";
String senha = "qualquer";
boolean resultado = login.checkCredentials(usuario, senha); //retorna true porque o usuario está no nosso map
assertEquals(resultado, true);
}
public void test_login_com_falha() {
UserDAO dao = new UserDAOStub(); //criando o nosso stub
Login login = new Login();
login.setUserDAO(dao); // setamos o login para usar o DAO fake
String usuario = "mario";
String senha = "outro";
boolean resultado = login.checkCredentials(usuario, senha); // retorna false porque o ousuario mario nao está no nosso 'banco de dados', o map
assertEquals(resultado, false);
}
}
Dessa maneira, testamos unitariamente a classe Login. O acesso ao banco de dados não deve ser testado no teste unitário (pois aí já não é teste unitário e sim integração) e simulamos duas situacoes: de um cara que colocou um login correto e outro que colocou um login incorreto.
Perceba que coloquei o nome dos métodos com underscore ao invés de Camel Case. A minha justifica é que, ao colocar com underscore as classes de teste, facilita muito mais a explicação do que aquele teste unitário está testando de verdade. É algo que você vê em qualquer relatório de testes e sabe que "aquele teste fez isso". Boas práticas não precisam ser seguidas a risca em testes unitários :) Mas discutir isso é discutir sexo dos anjos, então nem vale a pena entrar em detalhe.
O importante é que tu entendas a diferença desse teste com o teu teste
Quando tu pegar bem o jeito, sugiro que tu vá dar uma olhada em mocks, cobertura etc
