Há alguns dias eu mostrei aqui, que o WCF Web API possibilita a construção de serviços de modelo tradicional WCF, ou seja, definir tipos que refletem o nosso negócio (Cliente, Produto, Pedido, etc.), bem como tipos mais simples (inteiro, string, boleano, etc.). Como sabemos, a finalidade é conseguir desenhar um serviço que nada saiba sobre a infraestrutura, como ele é exposto, características, etc.

Naquela mesma oportunidade, eu comentei sobre a possibilidade que temos de receber e/ou retonar objetos que refletem e fazem uso da estrutura do protocolo HTTP, que é um detalhe muito importante na estrutura REST. Ao utilizar as classes que descrevem a requisição (HttpRequestMessage) e a resposta (HttpResponseMessage), podemos interagir com detalhes do protocolo, que antes exigia-se um conhecimento de baixo nível do WCF.

Como sabemos, assim como já acontece com os serviços tradicionais construídos em WCF, podemos aplicar testes em cima da classe que representa o serviço sem maiores problemas. Isso se deve ao fato de que em ambos os modelos que temos agora, como eles são simples classes, com métodos que executam tarefas e, eventualmente, retornam algum resultado.

Mas e quando queremos receber e/ou enviar dados para este serviço, utilizando instâncias das classes HttpRequestMessage e HttpResponseMessage? Felizmente, assim como no ASP.NET MVC, a Microsoft está desenhando o WCF Web API com a possibilidade de testá-lo sem estar acoplado à infraestrutura do WCF, o que permite testar a classe do serviço, mesmo que ela receba ou devolva objetos característicos do protocolo HTTP.

Se repararmos no artigo anterior, onde eu mostro um serviço que possui dois métodos (Ping e PingTipado), podemos escrever testes e, consequentemente, utilizar a IDE do Visual Studio para executá-los, e como isso, nos antecipamos à eventuais problemas que possam acontecer, pois talvez seja possível capturar alguns desses problemas antes mesmo de levar o mesmo ao ambiente de produção.

No primeiro exemplo, estamos testando o método Ping, instanciando a classe que representa o serviço, e passando ao método Ping a instância da classe HttpRequestMessage. Neste momento, poderíamos abastecer informações na coleção de headers da requisição, com o intuito de fornecer tudo o que é necessário para o que o método/teste possa executar com sucesso. Depois da requisição realizada, verificamos se o status da resposta corresponde ao status OK.

[TestMethod]
public void DadoUmaRequisicaoSimplesDeveRetornarStatusComoOK()
{
    var response = new ServicoDeExemplo().Ping(new HttpRequestMessage());

    Assert.AreEqual(HttpStatusCode.OK, response.StatusCode);
}

O próximo passo é construir um teste para o método PingTipado. Esse método recebe como parâmetro a instância da classe HttpRequestMessage<T>, definindo o parâmetro genérico T como sendo do tipo Informacao. A finalidade do teste é assegurar que, se passarmos uma instância nula da classe Informacao, uma exceção do tipo HttpResponseException deverá ser lançada. O código abaixo ilulstra este teste:

[TestMethod]
[ExpectedException(typeof(HttpResponseException))]
public void DadoUmObjetoInfoNuloDeveDispararUmErro()
{
    var response =
        new ServicoDeExemplo()
            .PingTipado(new HttpRequestMessage<Informacao>(null));
}

Finalmente, o próximo passo consiste em criar um teste, também para o método PingTipado, mas agora fornecendo a instância do objeto Informacao em um estado válido, para que o teste possa suceder se o serviço retornar a mesma instância da classe Informacao, onde os membros da requisição reflitam o que está sendo retornado como reposta. Abaixo o código que efetua o tal teste:

[TestMethod]
public void DadoUmObjetoInfoDeveRetornarEleComInformacoesExtra()
{
    var request = new Informacao() { Codigo = “123”, Dado = “Alguma Info” };
    var response =
        new ServicoDeExemplo()
            .PingTipado(new HttpRequestMessage<Informacao>(request))
            .Content
            .ReadAs();

    Assert.AreEqual(request.Dado, response.Dado);
}