Mockeando clientes HTTP
Clase 10 de 15 • Curso de Unit Testing en Go
Contenido del curso
Steven Javier Arevalo Poveda
student•
hace 4 años
María Camila Lenis Restrepo
teacher•
hace 4 años
Clase 10 de 15 • Curso de Unit Testing en Go
Contenido del curso
Steven Javier Arevalo Poveda
María Camila Lenis Restrepo
Xareni Wang Chen
María Camila Lenis Restrepo
Àlex Grau Roca
María Camila Lenis Restrepo
Rubens A. Rangel Gomez
fabio andres zamora osorio
María Camila Lenis Restrepo
Mi solución al reto:
func TestGetPokemosFromPokeApiNotFoundError(t *testing.T) { c := require.New(t) httpmock.Activate() defer httpmock.DeactivateAndReset() id := "bulbasaur" request := fmt.Sprintf("https://pokeapi.co/api/v2/pokemon/%s", id) httpmock.RegisterResponder("GET", request, httpmock.NewStringResponder(404, "")) _, err := GetPokemonFromPokeApi(id) c.NotNil(err) c.EqualError(ErrPokemonNotFound, err.Error()) }
Excelente, Steven 🤓
Genial! Una observación, como id se escribió "balbasaur" en vez de "bulbasaur" entonces, se me ocurre que una mejora del test sería hacer un assertion también con la url :D ¿Alguna otra idea para esto, o quizá no sea necesario para algunos?
Está super tu idea, Xareni. Nice catch
Les dejo en mi GitHub el poke_api_handler_test.go. . Para realizar este ejercicio he añadido la función GetPokemonApiUrl ara reducir la redundancia de distintas variables con el mismo nombre. Para el caso del success, he utilizado la función NewBytesResponder en lugar del NewStringResponder (ya que no tiene sentido convertir el body a string para luego volver a convertirlo a []byte). . Otra cosa relacionada con la anterior clase, en el caso del EqualError hay que tener en cuenta que el orden de los parámetros es (currentError, expectedErrorMessage). Aunque al final la validación funciona igual, en caso de error puede crear confusión, ya que mostrará los valores expected y actual invertidos.
Gracias por tu aporte Alex
🧠 Idea principal
Los mocks en llamadas a APIs no reemplazan tu función, sino que interceptan la llamada externa (HTTP) para simular respuestas y así poder probar tu lógica de forma controlada.
🧩 Fundamentos
1. Funcionamiento de los mocks en HTTP
GetPokemonFromPokeApi) sí se ejecuta.http.Get).2. Simulación de respuestas
3. Enfoque del testing
4. Optimización del código de test
string ↔ []byte).5. Validación de errores
EqualError.🔑 Puntos importantes
🎯 Conclusión
Mockear no elimina tu lógica, la protege del mundo externo para que puedas probarla con total control.
No entendi como funcionan los mocks, osea este codigo:
httpmock.RegisterResponder("GET", request, httpmock.NewStringResponder(200, string(body)))
reemplaza el codigo que hace la peticion el cual esta dentro de esta funcion:
GetPokemonFromPokeApi(id)
¿eso es asi o no?
Nop, la función GetPokemonFromPokeApi sigue siendo llamada y sigue ejecutandose lo que hay dentro, solo que cuanod vamos a hacer esa GET resquest, no la hacemos realmente, lo que nos va a retornar es un status 200 con ese body que pusimos en el mock.
El mock nos sirve para que no hagamos directamente las requests, sino que al momento de probar asumamos la respuesta deseada (ya sea que estemos probando el caso del 200 o cualquier otra respuesta) y así concentrarnos en probar NUESTRA funcionalidad, teniendo certeza que sabemos qué va a contestar el api