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:
[code]public interface UserDAO {
public User getUserByUsernameAndPassword(String username, String password);
}[/code]
2- Essa é a nossa classe de Login
[code]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;
}
}[/code]
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
[code]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;
}
}[/code]
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”
[code]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);
}
}[/code]
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
