Adicionando lentidão e códigos de erro - Criando uma API de exemplo em C# (Curso)

Tim Corey

16m 21s

Ao construir e testar aplicações modernas, especialmente aquelas com interfaces web, os desenvolvedores frequentemente se deparam com a necessidade de simular cenários do mundo real, como atrasos na API e respostas de erro inesperadas. Para ilustrar isso, Tim Corey apresenta um passo a passo bastante prático em sua aula intitulada " Adicionando lentidão e códigos de erro - Construindo uma API de exemplo em C# ". Neste vídeo, Tim ilustra como enriquecer uma API C# minimalista com atrasos artificiais e respostas de erro personalizadas — ferramentas valiosas para simular situações menos ideais durante os testes.

Neste artigo, vamos apresentar os conceitos e implementações que Tim demonstra no vídeo.

Introdução à API de exemplo e sua finalidade

Tim inicia a aula reiterando a importância de ter uma API de exemplo ao aprender desenvolvimento web. Uma API desse tipo oferece algo concreto para testar suas aplicações de front-end.

Ao final do curso, Tim pretende construir uma API robusta que inclua:

• Dados de exemplo

• Documentação

• Exames de saúde

• Simulações de desaceleração

• Erros simulados

• Opções de implantação via Docker e VPS

Nesta lição específica, Tim se concentra em simular lentidões e gerar códigos de erro para um comportamento realista da API em condições adversas.

Adicionando atrasos artificiais aos endpoints da API

Tim começa adicionando um parâmetro de atraso opcional a endpoints de API específicos — particularmente aqueles que lidam com dados de cursos. Seu objetivo é simular respostas lentas de API para melhores testes de front-end.

Detalhes da implementação:

• O parâmetro de atraso é um número inteiro que pode ser anulado e representa milissegundos.

• Para lidar com isso, Tim transforma os métodos de endpoint em métodos assíncronos (async) que retornam uma Task<IResult> em vez de apenas IResult.

• Se um atraso for fornecido e estiver dentro dos limites aceitáveis ​​(não excedendo 300.000 milissegundos ou 5 minutos), o método invoca Task.Delay() para pausar a execução.

Às 2h33 , Tim enfatiza a importância de limitar o atraso. Ele estabeleceu um limite de 5 minutos para evitar tempos de espera irrazoáveis ​​que poderiam tornar o aplicativo instável ou dar a impressão de estar com defeito.

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

Essa adição garante que os desenvolvedores possam simular atrasos de até cinco minutos, o que é útil para testar tempos limite e capacidade de resposta no aplicativo cliente.

Testando o mecanismo de atraso

Tim executa alguns testes usando o Postman (ou um clone do Postman) para verificar a lógica de atraso. Por exemplo:

• Um atraso de 5000 (5 segundos) faz com que a API pause antes de retornar os resultados.

• Um atraso de 500 resulta em uma pausa mais curta.

Ele observa que o atraso real será sempre ligeiramente maior do que o valor especificado devido à sobrecarga de processamento — uma nuance importante no mundo real. Como Tim observa aos 5:09 , você não está cronometrando a API até o milissegundo, mas sim simulando um limite.

Expandindo a funcionalidade de atraso para mais endpoints.

Tim não se contenta apenas com o ponto de extremidade "carregar todos os cursos". Ele busca consistência, então implementa a mesma capacidade de atraso no endpoint "carregar curso por ID".

Às 6h15 , ele se depara com um problema: um conflito de nomenclatura devido à adição automática de "Async" ao nome do método ao convertê-lo para assíncrono. Tim ajusta os nomes de ambos os métodos para que estejam em conformidade com a convenção de nomenclatura assíncrona, visando clareza e consistência.

Os testes confirmam a implementação:

• Os atrasos serão respeitados.

• Registros inexistentes retornam o código 404, como esperado, após o atraso.

• Remover o atraso ou passar valores vazios funciona corretamente, com Tim observando uma peculiaridade da interface do usuário no Postman em vez de um problema com a própria API ( 8:00 ).

Adicionando respostas de erro personalizadas

Em seguida, Tim apresenta uma ferramenta valiosa para testes de API: um endpoint dedicado que pode simular vários códigos de erro HTTP.

Às 9h13 , ele explica que, embora alguns endpoints (como o que retorna um curso por ID) retornem naturalmente o código 404 para dados ausentes, não há uma maneira integrada de testar outros códigos de erro — a menos que sejam simulados explicitamente.

Tim cria um novo endpoint em /error/{code} que:

• Aceita um código de status HTTP inteiro.

• Retorna a resposta de erro HTTP correspondente usando uma expressão switch.

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

Isso abrange tanto erros comuns do lado do cliente quanto quaisquer códigos personalizados que um desenvolvedor queira testar.

Às 12:03 , ele adiciona esse novo endpoint ao programa através de app.AddErrorEndpoints() e marca a classe de erro como estática.

Testando o ponto final de erro

Tim agora testa o endpoint de erro passando vários códigos de status:

• 400 retorna "Solicitação inválida"

• 401 retorna "Não autorizado"

• 404 retorna "Não encontrado"

• 301 retorna "Movido permanentemente"

• 405 retorna "Método não permitido"

Isso demonstra a flexibilidade do endpoint — não apenas para códigos de erro, mas para qualquer código de status HTTP. Às 13h04 , Tim confirma que essa abordagem é ideal para testar como os aplicativos de front-end lidam com diferentes respostas do servidor.

Embora tenha considerado nomeá-lo /httpcode, ele optou por /error por simplicidade, já que é usado principalmente para simular condições de erro.

Resumo das melhorias funcionais

Tim conclui o vídeo resumindo as melhorias feitas na API:

• As reduções de velocidade simulam a latência do mundo real nas respostas da API.

• A simulação de erros oferece flexibilidade para testar praticamente qualquer resposta HTTP.

• Esses recursos tornam a API de exemplo mais robusta e indispensável para cenários de teste realistas.

Às 14h16 , Tim destaca a importância dessas ferramentas para testar o comportamento do seu aplicativo em diferentes estados da API, como respostas atrasadas ou vários erros do servidor.

O que vem a seguir: Dockerizar a API

Embora não seja abordado em detalhes neste vídeo, Tim dá a entender qual será o próximo passo: a conteinerização da API. Isso permite que os desenvolvedores executem a API de exemplo localmente em um contêiner Docker independente, facilitando a implantação e o compartilhamento em diferentes ambientes.

Considerações finais

Tim encerra o vídeo reiterando seu compromisso em construir uma API de exemplo abrangente que inclua recursos realistas que os desenvolvedores realmente precisam para realizar testes. Esses recursos incluem:

• Atrasos

• Erros

• Exames de saúde

• Planos futuros para autenticação e endpoints avançados

O objetivo é simples, mas poderoso: fornecer aos desenvolvedores uma ferramenta que imite as peculiaridades das APIs reais, para que seus aplicativos sejam robustos, confiáveis ​​e fáceis de usar.

Conclusão

Ao final desta lição, os espectadores terão uma melhor compreensão de como e por que introduzir atrasos artificiais e respostas a erros em suas APIs. A abordagem de Tim Corey é metódica, prática e diretamente ligada às necessidades de teste de aplicações reais. Se você quer aprimorar suas habilidades em testes de API, esta lição é um excelente recurso a seguir — e agora você sabe exatamente onde procurar.

Assista à videoaula completa de Tim Corey para obter orientações práticas.