Rust / Componentes de un test

Bienvenidos sean a este post, hoy hablaremos sobre lo que compone una anatomia de un test.

Hasta ahora hemos visto como escribir un test y como correrlo, asi como unos atributos y macros para las verificaciones asi como tambien las formas de filtrarlo pero hoy nos centraremos sobre algunos temas que hemos visto pero no hemos mencionado o descripto en los posts anteriores, comencemos.

Test de unidad

El proposito de este tipo de test es para verifcar cada unidad de codigo aislado del resto del codigo para apuntar rapidamente donde esta o no trabajando el codigo, estas van dentro del directorio src y en cada archivo el codigo que se usara para testing, por convencion se crea un modulo llamado tests en cada archivo para contener las funciones de test y a cada modulo le pasamos el atributo [cfg(test)]

#[cfg(test)]

Esta anotacion o atributo le dice al compilador de Rust que esta porcion de codigo solo debe ejecutarse con cargo test y no con cargo build, esto nos ahorra tiempo de compilacion al momento de compilarlo y nos ahorra espacios en el compilado final porque omite todo el codigo de test, por esta razon los test de integracion al ir en un diferente directorio tampoco son incluidos al momento de compilarlo y en esos casos no es necesario usar esta anotacion, en cambio los test de unidad al ir en el directorio src necesitan de esta anotacion para ser omitidos al momento de compilarlo.

Test en funciones privadas

Este es un debate de las comunidades de lenguaje sobre si debe hacerse directamente o no en funciones privadas, y si bien en la mayoria de los lenguajes es bastante dificil en Rust si te permite hacerlos, por lo tanto no debemos preocuparnos si le usamos o no la palabra pub para hacerlo publico, esto es especialmente asi porque todo es codigo Rust y nos llevamos bien 😉

Test de integracion

Estas son enteramente externas a la libreria, y su objetivo es simular como seria utilizarla en codigo externo, lo cual implica que solo pueda llamar a las partes publicas de nuestra libreria, como pueden deducir su proposito es poder verificar la mayor parte del codigo que funcione correctamente junta, estas se realizan en el directorio tests.

Directorio tests

Este directorio se crea en el mismo nivel que src, dado que el compilador al verlo sabra que en este estaran todos los tests de intergracion, dentro de este podremos crear todos los test que necesitemos, si quieren verlo en accion les recomiendo ver este post donde vemos como crear un test de integracion para verificar el uso de test para un crate.

Submodulos en el test de integracion

Los test de integracion nos permite tambien tener submodulos para poder organizar mejor nuestros test, esto nos puede ser util para tener cada test bien identificado y permitirnos tener un mejor control sobre estos, es decir que los tratemos como distintos crates lo cual nos permite tener diferentes rangos o scopes pero esto involucra que no comparte la misma conducta que src, para verlo mejor les recomiendo este post.

Por ultimo los test se hacen unicamente en archivos lib.rs y no podremos hacerlo en main.rs, dado que los paquetes binarios estan destinados a ejeuctarse por si mismos, por esta razon en general los proyectos de Rust siempre tienen un binario simple que llaman a toda la logica contenida en multiples crates para poder tener los archivos lib.rs y podamos implementar todos los test comentados anteriormente.

En resumen, hoy hemos visto un poco mas detallado el porque de la estructura de un test, desde el simple que vimos hasta el de integracion que hemos visto al momento de crear nuestro crate, espero les haya sido de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.