Mockeando mux router
Contenido del curso
Mockeando mux router
Contenido del curso
Ejemplos de los tests con los codigos 404/500 de la API, en mi caso use assert de la misma libreria testify y t.Run para correo cada test y no llamarlos como una funcion:
t.Run("PokemonNotFoundError", func(t *testing.T) { r, err := http.NewRequest("GET", "/pokemon/{id}", nil) assert.NoError(t, err) w := httptest.NewRecorder() vars := map[string]string{ "id": "ssssssss", } r = mux.SetURLVars(r, vars) GetPokemon(w, r) assert.Equal(t, http.StatusNotFound, w.Code) }) t.Run("PokemonInternalServerError", func(t *testing.T) { r, err := http.NewRequest("GET", "/pokemon/{id}", nil) assert.NoError(t, err) w := httptest.NewRecorder() vars := map[string]string{ "id": "", } r = mux.SetURLVars(r, vars) GetPokemon(w, r) assert.Equal(t, http.StatusInternalServerError, w.Code) })
🧠 Idea principal
El testing de handlers (como los de un router HTTP) consiste en simular requests y responses para validar el comportamiento del endpoint, manteniendo el enfoque en pruebas unitarias siempre que el código esté aislado.
🧩 Fundamentos
1. Testing de handlers HTTP
http.NewRequest.httptest.NewRecorder.2. Uso de router (mux)
mux.SetURLVars)./pokemon/{id}.3. Validación de respuestas
200 → éxito404 → no encontrado500 → error interno4. Uso de subtests
t.Run se organizan múltiples escenarios en un solo test.5. Pruebas unitarias vs integración
🔑 Puntos importantes
httptest permite simular completamente el entorno HTTP.id).t.Run ayuda a estructurar múltiples casos.🎯 Conclusión
Testear handlers es simular el mundo HTTP de forma controlada, validando respuestas sin depender de un servidor real ni de servicios externos.
Fernando José Aguilar Rivas
Tengo un aporte y al mismo tiempo una pregunta.
A como yo catalogo esta clase esta prueba que realizamos seria una integration testing ya que probamos funcionalidad que va mas alla de una simple funcion o de una unidad. Me gustaria saber si estoy en lo cierto o me equivoco?
María Camila Lenis Restrepo
ProfesorHola Fernando, En las pruebas de integración quieres probar flujos, una funcionalidad más grande como por ejemplo 'quiero probar que el módulo de registro de usuarios funciona correctamente'. En cambio, en esta clase, no estamos probando un flujo, sino algo que podemos testear con una prueba pequeña.
Muchas veces separamos funciones, para que cada una tenga una responsabilidad y sea más fácil testear. El hecho de que testeemos una función que llama más funciones dentro no quiere decir que deje de ser una prueba unitaria. Porque seguimos testeando aisladamente del resto de nuestro sistema, no pensamos en todo el flujo.
Déjame saber si respondí tu pregunta 🤓 y gracias por tu aporte
Fernando José Aguilar Rivas
Excelente entonces por poner un ejemplo por decirlo asi un endpoint de una API digamos crear un usuario eso solo aplica como un prueba unitaria nada mas. Pero ya el conjunto de endpoints digamos crear y loguear usuario ya es un flujo por lo tanto ya aplican pruebas de integracion. Estoy en lo correcto?
Y muchas gracias por resolver mis dudas.
Brenthon Ramirez-Franco
Hola, buenas tardes, Dejo mi ejemplo de TestGetPokemonNotFoundError, saludos!
func TestGetPokemonNotFoundError(t *testing.T) { c := require.New(t) r, err := http.NewRequest("GET", "/pokemon/{id}", nil) c.NoError(err) w := httptest.NewRecorder() vars := map[string]string{ "id": "charizardo", } r = mux.SetURLVars(r, vars) GetPokemon(w, r) c.Equal(http.StatusNotFound, w.Code) }