Testeo Unitario de Funciones con MOOC en Go

Clase 21 de 30 • Curso de Go Intermedio: Programación Orientada a Objetos y Concurrencia

Resumen

¿Cómo implementar MOOC Functions para pruebas unitarias?

El arte de realizar pruebas unitarias nos permite validar que nuestro código esté funcionando correctamente y de manera eficiente, incluso cuando depende de otras funciones. Implementar MOOC Functions es una técnica poderosa que nos ayuda particularmente en este contexto. Aprenderemos cómo usar esta técnica de manera efectiva.

¿Qué son las MOOC Functions y por qué son útiles?

Las MOOC (Mock) Functions son versiones simuladas de funciones reales que nos permiten probar unidades de código en aislamiento. Al usarlas, podemos:

Simular comportamientos complejos: Sin necesidad de depender de funciones que podrían ser costosas o difíciles de ejecutar en un entorno de prueba.
Asegurar que las funciones principales están aisladas: Garantizando que la lógica principal se ejecuta correctamente sin interferencias.
Facilitar la detección de errores: Permitiendo cambios controlados en las respuestas de las funciones para verificar que se manejen adecuadamente los casos erróneos.

¿Cómo crear y utilizar las MOOC Functions en Go?

Paso 1: Definición de estructuras y valores de prueba

Primero, definimos nuestras estructuras y casos de prueba:

func main() {
    expectedEmployee := FullTimeEmployee{
        Person: Person{Age: 35, DNI: "1", Name: "Jungleu"},
        ID:     "1",
        Position: "CEO",
    }
}

Este bloque define un empleado con parámetros que utilizaremos en nuestras pruebas.

Paso 2: Almacenamiento y sustitución de funciones originales

Para modificar funciones adecuadamente sin perder sus versiones originales, las almacenamos:

originalGetEmployeeByID := getEmployeeByID
originalGetPersonByID := getPersonByID

Luego, reemplazamos las funciones originales con las Mooc Functions.

Paso 3: Uso de rangos y comparación de resultados

Iteramos sobre nuestra tabla de casos de prueba y evaluamos:

for _, test := range tests {
    ft, err := getFullTimeEmployeeByID(test.ID, test.DNI)
    if err != nil {
        log.Println("Error when getting employee:", err)
    }
    if ft.Person.Age != expectedEmployee.Person.Age {
        log.Printf("Expected age %d but got %d", expectedEmployee.Person.Age, ft.Person.Age)
    }
}

Es vital comparar propiedad por propiedad, siempre retornando las funciones originales al finalizar.

¿Cómo ejecutar y validar los resultados de las pruebas?

Utilizamos comandos específicos para ejecutar pruebas y verificar resultados. Con go test, podemos comprobar si nuestras pruebas pasan correctamente:

go test

Si unes estos conceptos con un enfoque meticuloso al almacenar y restaurar funciones, tu experiencia probando funciones complejas se enriquecerá notablemente.

Reflexiones finales y mejores prácticas

Fijar valores originales: Siempre mantén los valores originales de las funciones antes de hacer mocs.
Prueba cambios específicos: Experimenta cambiando valores de prueba para garantizar que las condiciones bajo prueba se comporten como se espera.
Frecuencia en las pruebas: Realiza pruebas de forma regular para captar errores de manera temprana y frecuente en el desarrollo.

Este conocimiento no solo te dará confianza en la funcionalidad de tu código, sino que también mejorará tu eficiencia en el desarrollo de software, ¡motivo por el que continúes sumergiéndote en este fascinante mundo de las pruebas unitarias!

Sebastian CA

student•

Para los que se preguntan porque hay tantos "errores" (lo rojo) en el codigo como se ve en esta parte:

Es porque el language server (gopls) no sabe como relacionar main.go y main_test.go porque no hacen parte de un go module. La "solucion" mas sencilla es recargar el language server. Si no, solo creen un go module:

$ go mod init testingmod

Victor Baruch Pazaran Jaimes

student•

Me quedaron algunas dudas respecto a este codigo, ya que no entedia muy bien como es que se reasignaban las funciones de "GetEmployeeById" y "GetPersonByDNI" si estaban fuera del scope de "mockFunc"

Así que decidí preguntarle al chat GPT y me aclaró muchas dudas, les comparto mi conversación traducida por si a alguien le puede servir a aclarar un poco mas el tema

YO:

Estoy trabajando con el siguiente código en go [le adjunté todo nuestro codigo] pero no entiendo muy bien lo que está haciendo, ¿podrías explicármelo?

GPT:

Este código es un caso de prueba para una función llamada GetFullTimeEmployeeById. El caso de prueba define una tabla de entradas y salidas esperadas de prueba, y luego recorre cada prueba en la tabla, ejecutando la función GetFullTimeEmployeeById con las entradas de la prueba y comparando su salida con la salida esperada.

Antes de ejecutar cada prueba, el código reasigna las funciones globales GetEmployeeById y GetPersonByDNI a funciones anónimas que devuelven valores codificados. Esto se hace para que la función GetFullTimeEmployeeById siempre devuelva la misma salida para una prueba dada, independientemente del estado actual del sistema.

El código también comprueba si ocurrió un error durante la ejecución de la prueba, y si se encuentra un error, la prueba lo registra Al final de la prueba, el código reasigna las funciones originales GetEmployeeById y GetPersonByDNI a las variables globales, para asegurarse de que la prueba no interfiera con otras partes del código que puedan estar utilizando estas funciones.

YO:

Gracias, pero todavía no entiendo cómo puede reasignar globalmente las funciones "GetEmployeeById" y "GetPersonByDNI" en el "mockFunc", ¿no se supone que el codigo reasigna las funciones sólo mientras están dentro de las llaves de "mockFunk"?

GPT:

Tienes razón en que, por defecto, la reasignación de las funciones GetEmployeeById y GetPersonByDNI dentro de la función mockFunc sólo duraría lo que dure la llamada a la función. Sin embargo, dado que estas funciones son variables globales, la reasignación dentro de la función mockFunc está cambiando efectivamente el valor de la variable global, y no sólo el valor de la variable local con el mismo nombre. Por lo tanto, los cambios en estas variables globales persisten fuera del ámbito de la función mockFunc.

También vale la pena señalar que, mientras reasigna las funciones globales dentro de mockFunc a funciones anónimas que devuelven valores codificados, también almacena las funciones originales en variables denominadas originalGetEmployeeById y originalGetPersonByDNI respectivamente. Esto se hace para que el código pueda restaurar las funciones originales una vez finalizado el caso de prueba, para evitar afectar al estado del sistema una vez finalizado el caso de prueba.

YO:

De acuerdo, ahora lo entiendo mejor, pero tengo otra pregunta, ¿por qué las funciones almacenadas en las variables "originalGetEmployeeById" y "originalGetPersonByDNI" no se ven afectadas cuando "mockFunc" hace el cambio, si esas variables son las mismas funciones no se supone que deben cambiar también?

GPT:

Tienes razón en que originalGetEmployeeById y originalGetPersonByDNI almacenan los valores de las variables globales GetEmployeeById y GetPersonByDNI en el momento en que se asignan por primera vez. Sin embargo, cuando se llama a la función mockFunc y ésta reasigna las variables globales GetEmployeeById y GetPersonByDNI, no cambia los valores almacenados en las variables originalGetEmployeeById y originalGetPersonByDNI. Estas son dos variables separadas, con diferentes valores almacenados en ellas.

Es importante entender que las variables en Go se pasan por valor, lo que significa que cuando asignas una variable a otra, se almacena una copia del valor en la nueva variable, no una referencia al valor original. Así, cuando a originalGetEmployeeById y originalGetPersonByDNI se les asigna el valor de GetEmployeeById y GetPersonByDNI, se les da una copia de los valores de esas variables, no una referencia a las variables mismas. Por lo tanto, cuando GetEmployeeById y GetPersonByDNI se reasignan en el mockFunc, esto no afecta a los valores almacenados en originalGetEmployeeById y originalGetPersonByDNI.

Walter Jerusalinsky

student•

sorpendente!

Miguel Angel Reyes Moreno

student•

Este es un buen uso que se le debe dar a la IA

Gonzalo Muñoz

student•

Hay una librería llamada Mockery, que te genera los Mocks automáticamente utilizando un comando.

Una vez te genera un mock, es llegar y utilizarlo. Muy fácil y practico. Dejo el proyecto para que le echen una mirada: https://github.com/vektra/mockery

Sebastian Villegas

student•

También se puede hacer uso de

reflect.DeepEqual()

Para comparar objetos sin tener que ir propiedad por propiedad, en este caso quedaría así la única condicional:

if !reflect.DeepEqual(ft, test.expectedEmployee) {
	t.Errorf("Not equal employees, \nExpected: %v\nGot: %v" , ft , test.expectedEmployee)
}

Juan Pablo Meza Gazabón

student•

Hola gente, aquí les dejo mis apuntes del Apartado de testing con golang, por si quieren revisarlo jeje https://plump-flare-484.notion.site/Testing-c945f250509e449d8b9dee247bdc63a6

Carlos Nassif Trejo Garcia

student•

package main

import "testing"

func TestGetFullTimeEmployeeById(t *testing.T) {
	table := []struct {
		id               int
		dni              string
		mockFunc         func()
		expectedEmployee FullTimeEmployee
	}{
		{
			id:  1,
			dni: "12345678",
			mockFunc: func() {
				GetEmployeeByID = func(id int) (Employee, error) {
					return Employee{
						Id:       1,
						Position: "CEO",
					}, nil
				}

				GetPersonByDNI = func(dni string) (Person, error) {
					return Person{
						Name: "John Doe",
						Age:  35,
						DNI:  "12345678",
					}, nil
				}
			},
			expectedEmployee: FullTimeEmployee{
				Person: Person{
					Age:  35,
					DNI:  "12345678",
					Name: "John Doe",
				},
				Employee: Employee{
					Id:       1,
					Position: "CEO",
				},
			},
		},
	}

	// Save the original functions
	originalGetEmployeeByID := GetEmployeeByID
	originalGetPersonByDNI := GetPersonByDNI

	for _, test := range table {
		// Set the mock functions for the test
		test.mockFunc()

		// Call the function to test
		ft, err := GetFullTimeEmployeeById(test.id, test.dni)
		if err != nil {
			t.Errorf("Error getting full time employee by id: %v", err)
		}

		// Check if the result is the expected
		if ft.Age != test.expectedEmployee.Age {
			t.Errorf("Expected age %v, got %v", test.expectedEmployee.Person.Age, ft.Person.Age)
		}

		if ft.DNI != test.expectedEmployee.DNI {
			t.Errorf("Expected dni %v, got %v", test.expectedEmployee.Person.DNI, ft.Person.DNI)
		}

		if ft.Name != test.expectedEmployee.Name {
			t.Errorf("Expected name %v, got %v", test.expectedEmployee.Person.Name, ft.Person.Name)
		}

		if ft.Employee.Id != test.expectedEmployee.Employee.Id {
			t.Errorf("Expected employee id %v, got %v", test.expectedEmployee.Employee.Id, ft.Employee.Id)
		}

		if ft.Employee.Position != test.expectedEmployee.Employee.Position {
			t.Errorf("Expected employee position %v, got %v", test.expectedEmployee.Employee.Position, ft.Employee.Position)
		}
	}

	// Restore the original functions
	GetEmployeeByID = originalGetEmployeeByID
	GetPersonByDNI = originalGetPersonByDNI
}

Aaron Contreras Garibay

student•

entonces, como regla general lo mejor es declarar las funciones en go con la sintaxis de

var FuncName = func{}

? Y asi poder hacerles mock ahora o en el futuro.

Andres de Jesus Romo Quintero

student•

¿Qué sucede cuando implementas tus pruebas y funcionan como esperas, pero pruebas tu código ya sea por postman y este no funciona?

Cristian Blandon

student•

Si has hecho las pruebas como Néstor ha enseñado, es necesario tener en cuenta que los tests probarán únicamente el funcionamiento específico de tu código, sin tener en cuenta ninguna dependencia externa. Así las cosas, te diría que es probable que lo que esté causando que tu código no funcione sea una dependencia externa y es allí donde debes revisar.

Yorman Alonso Salgado Valencia

student•

Hola si no en vez de una función tengo un método óseo sin retorno o esta llama a otra función o método ¿Como lo testeo?

Jaime David Burbano Montoya

student•

Si tienes un método que no retorna algo, no importa. Ese método hace alguna cosa, por lo cual se debería probar esa cosa. Por ejemplo, si tengo un método que le cambia el valor a una variable, puedes probar que esa variable cambie de valor después de ejecutar la función.

Por otro lado, si tienes una función que ejecuta otra función, puedes seguir el ejemplo anterior, o a lo mejor no tendría mucho sentido probar ese método.

El coverage de los test del 100% es una utopía en el mundo laboral. Generalmente, no es necesario probar tooooooooooodo el código

Rafael E Díaz M

student•

Hola. @Nestor Escoto. No se podría hacer una especie de función test para GetEmployeeById y GetPersonByDNI y llamar dentro del test de GetFullTime EmployeeById? o rompe con el paradigma de test unitario? De todos modos quisiera saber si es posible hacerlo.

Jaime David Burbano Montoya

student•

En teoria, según entiendo lo que preguntas. No tendría mucho sentido. Pues estaría probando una función totalmente diferente a la original, por lo cual seria una especie de prueba falsa.

Christian Car

student•

Interesante el uso de mocks

En que parte de los cursos de golang, se enseña la parte de debugging?

Carlos Daniel Bonilla Ramirez

student•

NO entendi bien lo de los orginalGetEmployeeById Para que sirve especificar eso?

Santiago Ortiz Ceballos

student•

Por qué en vez de sobre-escribir las funciones originales en el mock, no se declaran con un nombre diferente y se evita dicha necesidad de guardarlas en otras variables durante el test?

Juan David Mantilla López

student•

Se me hizo bastante complicado entender cómo funcionan los mocks en Go, y más aún cuando hay que reestablecer el funcionamiento de las funciones globales originales.

Gabriel Arispe

student•

Basicamente una manera de no esperar la ejecucion de una funcion para que te devuelva su valor si no devolver los valores de manera directa para ahorrar tiempo.

Carlos Nexans

student•

Se entiende el concepto de poder mockear, reemplazando la implementación y restaurándola al final. Recomendaría evitar este método, dado que la implementación se puede reemplazar en un test, como en el programa original.

Además, el programador se puede olvidar fácilmente de hacer alguna restauración y traiga consecuencias inesperadas en el resultado de las pruebas unitarias.

En otras aportaciones se comentaron herramientas para generar mocks de forma automatizada, esto es una mejor solución. Agrego que es preferible evitar los mocks y los efectos secundarios cuando sea posible, hace que el comportamiento del código más predecible.

Juan Camilo Colorado Cardona

student•

Si quieren mantener las funciones asi:

func GetEmployeeById(id int) (Employee, error) { //time.Sleep(5 * time.Second) // This is like simulatating a query to a database return Employee{ id: id, }, nil} func GetPersonByDNI(dni string) (Person, error) { //time.Sleep(5 * time.Second) return Person{ dni: dni, }, nil}

Pueden hacer el test de esta forma usando la libreria de testify/mock:

package main import ( "testing" "github.com/stretchr/testify/assert" "github.com/stretchr/testify/mock") type PersonMock struct { mock.Mock} type EmployeeMock struct { mock.Mock} func (m *EmployeeMock) GetEmployeeById(id int) (Employee, error) { args := m.Called(id) return args.Get(0).(Employee), args.Error(1)} func (m *PersonMock) GetPersonByDNI(dni string) (Person, error) { args := m.Called(dni) return args.Get(0).(Person), args.Error(1)} func TestGetFullTimeEmployeeById_Success(t *testing.T) { // Arrange expectedEmployee := FullEmployee{ Person: Person{dni: "12345678A"}, Employee: Employee{id: 1}, } // Mocks mockEmployeeDB := new(EmployeeMock) mockEmployeeDB.On("GetEmployeeById", 1).Return(Employee{id: 1}, nil) mockPersonDB := new(PersonMock) mockPersonDB.On("GetPersonByDNI", "12345678A").Return(Person{dni: "12345678A"}, nil) // Act result, err := GetFullTimeEmployeeById(1, "12345678A") // Assert assert.NoError(t, err) assert.Equal(t, expectedEmployee, result)}

Lo que pasa es que esas funciones GetPersonByDNI y getEmployeeById, estaban enviando un struct vacio, con esa correcion pueden ver otra forma de ver la implemntacion con testify/mock

Testeo Unitario de Funciones con MOOC en Go

Introducción

Programación Orientada a Objetos y Concurrencia en Go

Concurrencia y Testing en Go: Go Routinas y Worker Pools

Fundamentos de Programación en Go: Structs, Apuntadores y Manejo de Errores

Go Routines, Canales y Apuntadores en Golang

Programación orientada a objetos

Programación Orientada a Objetos en Go: Análisis y Comparativa

Equivalente de Clases en Go: Uso de Structs y Propiedades

Métodos en Structs: Implementación de Receiver Functions en Go

Implementación de Constructores en Go: Ejemplos y Mejores Prácticas

Herencia y Composición en Programación Orientada a Objetos

Interfaces y Polimorfismo en TypeScript y Go

Patrón Abstract Factory: Interfaces y Polimorfismo en Go

Implementación del Patrón Factory en Go para Notificaciones

Funciones Anónimas en Go: Uso y Consideraciones Prácticas

Funciones Variádicas y Retornos con Nombre en Go

Go Modules

Manejo de Dependencias y Módulos en Go

Creación y Publicación de Módulos en GitHub con Go

Testing

Tests unitarios y code coverage en Go

Cobertura de Código y Testing en Go: Mejorando la Calidad del Software

Profiling de Código en Go para Optimización de Rendimiento

Testing Unitario en Go: Uso de Mock Services