Ao desenvolver uma aplicação que se conecta com alguns servidores através de sockets, tive dificuldades para identificar uma forma prática e confiável de testar o código responsável pela comunicação com o servidor.
Pesquisei bastante pela Internet e a maioria das referências que encontrei indicavam o uso de Mocks para simular a conexão.
Eu não fiquei satisfeito com isso, pois queria testar a camada de rede sob condições no mínimo realistas. Então escrevi uma classe EchoServer que levanta um servidor em uma determinada porta, recebe textos dos clientes e os envia de volta.
Essa abordagem deve resolver as dificuldades de testes, e gerar testes confiáveis para a grande maioria das aplicações que abrem sockets para trocar textos com servidores.
Apesar de a classe não ter nada demais, e ser praticamente igual às que devem ser encontradas em qualquer livro sobre java.nio, ela está disponível neste artigo para aqueles que a quiserem.
If you enjoyed this article, please consider sharing it!
Cabeça a finalidade do teste unitário é justamente testar a sua classe, a sua lógica, por isso o uso de mocks, não vejo a necessidade de criar um servidor e testar uma conexão real, pois assim você esta testando o correto funcionamento da api de terceiros, do servidor, do socket, da rede, etc…
Esta mais p/ um mini teste de integração.
Um mock p/ cada possibilidade de saída do socket bastaria, resposta ok, exceptions, resposta malformada, etc…
Se sua classe respondeu corretamente a todas as possibilidades dos mocks, diria que sua classe esta ok.
Rafa, eu entendo que quando nós trabalhamos com Java, nós simplesmente assumimos que a API disponibilizada pelo fornecedor da nossa JVM está correta e ponto.
Fiquei desconfortável com mockar a camada de rede por conta da natureza assíncrona desses códigos, e achei que submete-la à testes mais próximos da realidade deles seria bom.
Por outro lado, quando eu mocko para isolar o meu código do ambiente com o qual ele vai interagir em runtime, eu tenho que me certificar de que estou testando aspectos realmente importantes do código, e que estou testando todos os aspectos importantes. Nesse caso eu mantive alguns testes com mock, mas achei importante testar também esse aspecto assíncrono e paralelo da aplicação, e não consegui fazer isso mockando.