Cuando hacemos bibliotecas en general, resulta muy difícil poder abarcar todas las posibilidades, por mucho que pensemos, y analicemos.

Sin ir más lejos, esta última semana me encontré con que tenía que hacer algunos cambios en nuestra biblioteca common, para facilitar serializar (almacenar binariamente, en este caso, ya que serializando a XML no necesitaba modificar nada). Pero de eso hablaremos después.

El punto es que, tarde o temprano, modificaremos nuestro código, lo cual no está para nada mal… se llama evolución J

Esto nos lleva a la necesidad tener previstos mecanismos para comprobar que los cambios no afecten las funcionalidades que ya teníamos aseguradas y probadas.

Cuanto más evolucionemos nuestras bibliotecas, más complejos serán los pasos para volver a probar que todo funcione como esperamos.

Es por ello que existen los proyectos de tipo prueba, que incluye no solo esta opción (probar bibliotecas) sino que abarca pruebas de interfaz, de rendimiento, etc.

Pero, hoy, hablaremos de pruebas para nuestras funciones, o Pruebas Unitarias

Es de considerar que un mismo proyecto de pruebas, podrá aplicarse a múltiples bibliotecas, e inclusive hasta es conveniente, dado que nos permitirá automatizar pruebas múltiples en el tiempo.

Procedamos, pues, a agregar un proyecto de pruebas.

El proyecto expone contiene clases de pruebas unitarias, marcadas como TestClass (por atributo).

Además, cada método que debe cumplir una prueba, se decora con el atributo TestMethod.

¿Y por qué es esto?

Sencillamente, porque un motor de pruebas, embebido en Visual Studio, reconoce dicha clases y métodos, para ejecutarlos cada vez que se requiera hacer las pruebas.

Team Foundation Server (Y Visual Studio Online), poseen motores de pruebas parecidos.

 

Anunciar si la prueba fue satisfactoria o no.

Cada método de prueba es un procedimiento, que hace lo necesario para llamar una función (o inclusive más).

Dicho método debe reportar al motor de pruebas si ésta fue satisfactoria. Y esto se hace utilizando Assert (Afirmar, aseverar), que dispone de varios métodos de respuesta lógica, como «Es Igual», «Es Distinto», etc.

Así el motor sabe, cuando las pruebas se realizan en modo automatizado, el resultado en cada caso.

Veamos por ejemplo, una prueba unitaria de nuestra biblioteca de recursos.

[TestClass]
public class Resources
{
    [TestMethod]
    public void GetString()
    {
        string result = DS.Resources.Resources.ErrorTitle;
        string lang = System.Threading.Thread.CurrentThread.CurrentUICulture.TwoLetterISOLanguageName;
        Assert.AreEqual(result, lang==«en» ? «Operation error»: «Error en la operación»);
    }
}

 

Finamente, podemos probar individualmente un método, e inclusive depurar el proceso de prueba, en el entorno de Visual Studio, con el menú contextual que aparece en cualquiera de los métodos marcados como de prueba.

Evaluando resultados

Al ejecutarse las mismas, el Explorador de Prueba, en Visual Studio, nos presenta los resultados.

En la imagen se muestran las pruebas de varios métodos de todas las bibliotecas de las que hemos hablado.