Pruebas para código y código para pruebas

En lenguajes dinámicos, como python y javascript, es posible reemplazar métodos y clases en módulos directamente durante la operación. Esto es muy conveniente para las pruebas: simplemente puede poner "parches" que excluirán la lógica pesada o innecesaria en el contexto de esta prueba.

¿Pero qué hacer en C ++? Ir? Java? En estos idiomas, el código no puede modificarse para las pruebas sobre la marcha, y la creación de parches requiere herramientas separadas.

En tales casos, debe escribir específicamente el código para que se pruebe. Esto no es solo un deseo maníaco de ver una cobertura del 100% en su proyecto. Este es un paso hacia la escritura de código compatible y de calidad.

En este artículo, trataré de hablar sobre las ideas principales detrás de la escritura de código comprobable y mostrar cómo se pueden usar con un ejemplo de un programa simple.

Programa sin complicaciones

Escribiremos un programa simple para realizar una solicitud a la API de VK. Este es un programa bastante simple que genera una solicitud, la hace, lee la respuesta, decodifica la respuesta de JSON en una estructura y muestra el resultado al usuario.

package main import ( "encoding/json" "fmt" "io/ioutil" "net/http" "net/url" ) const token = "token here" func main() { //     var requestURL = fmt.Sprintf( "https://api.vk.com/method/%s?&access_token=%s&v=5.95", "users.get", token, ) //   resp, err := http.PostForm(requestURL, nil) //   if err != nil { fmt.Println(err) return } //       defer resp.Body.Close() //     body, err := ioutil.ReadAll(resp.Body) //   if err != nil { fmt.Println(err) return } //      var result struct { Response []struct { ID int `json:"id"` FirstName string `json:"first_name"` LastName string `json:"last_name"` } `json:"response"` } //        err = json.Unmarshal(body, &result) //   if err != nil { fmt.Println(err) return } // ,    if len(result.Response) < 1 { fmt.Println("No values in response array") return } //    fmt.Printf( "Your id: %d\nYour full name: %s %s\n", result.Response[0].ID, result.Response[0].FirstName, result.Response[0].LastName, ) } 

Como profesionales en nuestro campo, decidimos que era necesario escribir pruebas para nuestra aplicación. Crea un archivo de prueba ...

 package main import ( "testing" ) func Test_Main(t *testing.T) { main() } 

No se ve muy atractivo. Esta comprobación es un simple lanzamiento de una aplicación en la que no podemos influir. No podemos excluir el trabajo con la red, verificar la operabilidad de varios errores e incluso reemplazar el token para la verificación fallará. Intentemos descubrir cómo mejorar este programa.

Patrón de inyección de dependencia

Primero debe implementar el patrón de "inyección de dependencia" .

 type VKClient struct { Token string } func (client VKClient) ShowUserInfo() { var requestURL = fmt.Sprintf( "https://api.vk.com/method/%s?&access_token=%s&v=5.95", "users.get", client.Token, ) // ... } 

Al agregar una estructura, creamos una dependencia (clave de acceso) para la aplicación, que puede transferirse desde diferentes fuentes, lo que evita los valores "cableados" y simplifica las pruebas.

 package example import ( "testing" ) const workingToken = "workingToken" func Test_ShowUserInfo_Successful(t *testing.T) { client := VKClient{workingToken} client.ShowUserInfo() } func Test_ShowUserInfo_EmptyToken(t *testing.T) { client := VKClient{""} client.ShowUserInfo() } 

Separación de la recepción de información y su salida.

Ahora solo una persona puede cometer un error, y solo si sabe cuál debería ser la conclusión. Para resolver este problema, es necesario no enviar información directamente a la secuencia de salida, sino agregar métodos separados para obtener información y su salida. Estas dos partes independientes serán más fáciles de verificar y mantener.

GetUserInfo() método GetUserInfo() , que devolverá una estructura con información del usuario y un error (si sucedió). Dado que este método no genera nada, los errores que ocurren se transmitirán aún más sin salida, de modo que el código que necesita los datos resolverá la situación.

 type UserInfo struct { ID int `json:"id"` FirstName string `json:"first_name"` LastName string `json:"last_name"` } func (client VKClient) GetUserInfo() (UserInfo, error) { var requestURL = fmt.Sprintf( "https://api.vk.com/method/%s?&access_token=%s&v=5.95", "users.get", client.Token, ) resp, err := http.PostForm(requestURL, nil) if err != nil { return UserInfo{}, err } // ... var result struct { Response []UserInfo `json:"response"` } // ... return result.Response[0], nil } 

Cambie ShowUserInfo() para que use GetUserInfo() y maneje los errores.

 func (client VKClient) ShowUserInfo() { userInfo, err := client.GetUserInfo() if err != nil { fmt.Println(err) return } fmt.Printf( "Your id: %d\nYour full name: %s %s\n", userInfo.ID, userInfo.FirstName, userInfo.LastName, ) } 

Ahora en las pruebas puede verificar que se recibe la respuesta correcta del servidor, y si el token es incorrecto, se devuelve un error.

 func Test_GetUserInfo_Successful(t *testing.T) { client := VKClient{workingToken} userInfo, err := client.GetUserInfo() if err != nil { t.Fatal(err) } if userInfo.ID == 0 { t.Fatal("ID is empty") } if userInfo.FirstName == "" { t.Fatal("FirstName is empty") } if userInfo.LastName == "" { t.Fatal("LastName is empty") } } func Test_ShowUserInfo_EmptyToken(t *testing.T) { client := VKClient{""} _, err := client.GetUserInfo() if err == nil { t.Fatal("Expected error but found <nil>") } if err.Error() != "No values in response array" { t.Fatalf(`Expected "No values in response array", but found "%s"`, err) } } 

Además de actualizar las pruebas existentes, debe agregar nuevas pruebas para el método ShowUserInfo() .

 func Test_ShowUserInfo(t *testing.T) { client := VKClient{workingToken} client.ShowUserInfo() } func Test_ShowUserInfo_WithError(t *testing.T) { client := VKClient{""} client.ShowUserInfo() } 

Alternativas personalizadas

Las pruebas para ShowUserInfo() parecen a lo que intentamos escapar inicialmente. En este caso, el único punto del método es enviar información a la secuencia de salida estándar. Por un lado, puede intentar redefinir os.Stdout y verificar la salida, parece una solución demasiado redundante cuando puede actuar con más elegancia.

En lugar de usar fmt.Printf , puede usar fmt.Fprintf , que le permite io.Writer a cualquier io.Writer . os.Stdout implementa esta interfaz, que nos permite reemplazar fmt.Printf(text) con fmt.Fprintf(os.Stdout, text) . Después de eso, podemos colocar os.Stdout en un campo separado, que se puede establecer en los valores deseados (para pruebas, una cadena, para el trabajo, un flujo de salida estándar).

Dado que la capacidad de cambiar Writer para la salida rara vez se utilizará, principalmente para pruebas, tiene sentido establecer un valor predeterminado. A continuación, para esto haremos esto: hacer que el tipo VKClient exportable y crear una función de constructor para él.

 type vkClient struct { Token string OutputWriter io.Writer } func CreateVKClient(token string) vkClient { return vkClient{ token, os.Stdout, } } 

En la función ShowUserInfo() , reemplazamos las llamadas Print con Fprintf .

 func (client vkClient) ShowUserInfo() { userInfo, err := client.GetUserInfo() if err != nil { fmt.Fprintf(client.OutputWriter, err.Error()) return } fmt.Fprintf( client.OutputWriter, "Your id: %d\nYour full name: %s %s\n", userInfo.ID, userInfo.FirstName, userInfo.LastName, ) } 

Ahora necesita actualizar las pruebas para que creen el cliente utilizando el constructor e instalen otro escritor cuando sea necesario.

 func Test_ShowUserInfo(t *testing.T) { client := CreateVKClient(workingToken) buffer := bytes.NewBufferString("") client.OutputWriter = buffer client.ShowUserInfo() result, _ := ioutil.ReadAll(buffer) matched, err := regexp.Match( `Your id: \d+\nYour full name: [^\n]+\n`, result, ) if err != nil { t.Fatal(err) } if !matched { t.Fatalf(`Expected match but failed with "%s"`, result) } } func Test_ShowUserInfo_WithError(t *testing.T) { client := CreateVKClient("") buffer := bytes.NewBufferString("") client.OutputWriter = buffer client.ShowUserInfo() result, _ := ioutil.ReadAll(buffer) if string(result) != "No values in response array" { t.Fatal("Wrong error") } } 

Para cada prueba en la que producimos algo, creamos un búfer que desempeñará el papel de una secuencia de salida estándar. Después de ejecutar la función, se verifica que los resultados se correspondan con nuestras expectativas, con la ayuda de expresiones regulares o una simple comparación.

¿Por qué estoy usando expresiones regulares? Para que las pruebas funcionen con cualquier token válido que proporcionaré al programa, independientemente del nombre de usuario y la ID de usuario.

Patrón de inyección de dependencia - 2

Por el momento, el programa tiene una cobertura del 86,4%. ¿Por qué no 100%? No podemos provocar errores de http.PostForm() , ioutil.ReadAll() y json.Unmarshal() , lo que significa que no podemos verificar cada " return UserInfo, err ".

Para tener aún más control sobre la situación, debe crear una interfaz en la que se ajuste http.Client , http.Client implementación estará en vkClient y se utilizará para las operaciones de red. Para nosotros, en la interfaz, solo un método es PostForm : PostForm .

 type Networker interface { PostForm(string, url.Values) (*http.Response, error) } type vkClient struct { Token string OutputWriter io.Writer Networker Networker } func CreateVKClient(token string) vkClient { return vkClient{ token, os.Stdout, &http.Client{}, } } 

Tal movimiento elimina la necesidad de realizar operaciones de red en general. Ahora podemos simplemente devolver los datos esperados de VKontakte usando el falso Networker . Por supuesto, no se deshaga de las pruebas que verificarán las solicitudes al servidor, pero no es necesario realizar solicitudes en cada prueba.

Crearemos implementaciones para el Networker y Reader falsos, de modo que podamos probar los errores en cada caso, a pedido, al leer el cuerpo y durante la deserialización. Si queremos un error al llamar a PostForm, simplemente lo devolvemos en este método. Si queremos un error
al leer el cuerpo de la respuesta, es necesario devolver un Reader falso, que arrojará un error. Y si necesitamos que el error se manifieste durante la deserialización, entonces devolvemos la respuesta con una cadena vacía en el cuerpo. Si no queremos ningún error, simplemente devolvemos el cuerpo con el contenido especificado.

 type fakeReader struct{} func (fakeReader) Read(p []byte) (n int, err error) { return 0, errors.New("Error on read") } type fakeNetworker struct { ErrorOnPostForm bool ErrorOnBodyRead bool ErrorOnUnmarchal bool RawBody string } func (fn *fakeNetworker) PostForm(string, url.Values) (*http.Response, error) { if fn.ErrorOnPostForm { return nil, fmt.Errorf("Error on PostForm") } if fn.ErrorOnBodyRead { return &http.Response{Body: ioutil.NopCloser(fakeReader{})}, nil } if fn.ErrorOnUnmarchal { fakeBody := ioutil.NopCloser(bytes.NewBufferString("")) return &http.Response{Body: fakeBody}, nil } fakeBody := ioutil.NopCloser(bytes.NewBufferString(fn.RawBody)) return &http.Response{Body: fakeBody}, nil } 

Para cada situación problemática, agregamos una prueba. Crearán un Networker falso con la configuración necesaria, según la cual arrojará un error en un momento determinado. Después de eso, llamamos a la función para que se verifique y nos aseguramos de que ocurriera un error, y de que esperábamos este error.

 func Test_GetUserInfo_ErrorOnPostForm(t *testing.T) { client := CreateVKClient(workingToken) client.Networker = &fakeNetworker{ErrorOnPostForm: true} _, err := client.GetUserInfo() if err == nil { t.Fatal("Expected error but none found") } if err.Error() != "Error on PostForm" { t.Fatalf(`Expected "Error on PostForm" but got "%s"`, err.Error()) } } func Test_GetUserInfo_ErrorOnBodyRead(t *testing.T) { client := CreateVKClient(workingToken) client.Networker = &fakeNetworker{ErrorOnBodyRead: true} _, err := client.GetUserInfo() if err == nil { t.Fatal("Expected error but none found") } if err.Error() != "Error on read" { t.Fatalf(`Expected "Error on read" but got "%s"`, err.Error()) } } func Test_GetUserInfo_ErrorOnUnmarchal(t *testing.T) { client := CreateVKClient(workingToken) client.Networker = &fakeNetworker{ErrorOnUnmarchal: true} _, err := client.GetUserInfo() if err == nil { t.Fatal("Expected error but none found") } const expectedError = "unexpected end of JSON input" if err.Error() != expectedError { t.Fatalf(`Expected "%s" but got "%s"`, expectedError, err.Error()) } } 

Usando el campo RawBody , puede deshacerse de las solicitudes de red (solo devuelva lo que esperamos recibir de VKontakte). Esto puede ser necesario para evitar exceder los límites de consulta durante las pruebas o para acelerar las pruebas.

Resumen

Después de todas las operaciones en el proyecto, recibimos un paquete de 91 líneas de largo (+170 líneas de pruebas), que admite la salida a cualquier io.Writer , le permite usar métodos alternativos de trabajo con la red (usando el adaptador a nuestra interfaz), en el que hay un método como para generar datos y obtenerlos. El proyecto tiene una cobertura del 100%. Las pruebas verifican completamente cada respuesta de línea y aplicación a cada posible error.

Cada paso en el camino hacia una cobertura del 100% aumentó la modularidad, el mantenimiento y la confiabilidad de la aplicación, por lo que no hay nada de malo en el hecho de que las pruebas dictaron la estructura del paquete.

La capacidad de prueba de cualquier código es una cualidad que no aparece desde el aire. La capacidad de prueba aparece cuando el desarrollador usa patrones adecuadamente en situaciones apropiadas y escribe código personalizado y modular. La tarea principal era mostrar el proceso de pensamiento al realizar programas de refactorización. Un pensamiento similar puede extenderse a cualquier aplicación y biblioteca, así como a otros idiomas.