En conclusión

Este es un extracto del eBook de Unit Testing Succinctly, por Marc Clifton, amablemente proporcionado por Syncfusion.

La prueba de unidad también es valiosa para otros propósitos.

Como ejemplos de uso

Uno de los beneficios secundarios de las pruebas unitarias es que crea una base de código grande que ejemplifica cómo usar el código. Por ejemplo, el código que vimos anteriormente:

[Prueba] public void FilenameParsingTest () Dictionary options = CommandLineParser.Parse ("- f foobar"); Assert.That (options.Count == 1, "Count se espera que sea 1"); Assert.That (options.ContainsKey ("- f"), "Opción esperada '-f'"); Assert.That (opciones ["- f"] == "foobar");

documenta un caso de uso válido esperado para el analizador de línea de comandos. También considere escribir pruebas unitarias, no solo para su propio código, sino también para proporcionar ejemplos de bibliotecas de terceros. (Ver ejemplos posteriores y las cosas interesantes reveladas sobre la estructura del Rectángulo).

Prueba de caja negra

Las pruebas de caja negra asumen que usted no sabe nada sobre los aspectos internos de la clase o servicio y está verificando su comportamiento estrictamente desde las interfaces expuestas públicamente. Esto es frecuentemente necesario cuando no tienes el código disponible. Por ejemplo, cuando trabajamos con una empresa de gestión de registros, se nos exigió utilizar un servicio web proporcionado por una agencia gubernamental para actualizar los registros. Al escribir pruebas unitarias para el servicio web, pudimos demostrar que la documentación proporcionada no resultó en el comportamiento esperado del servicio web..

Puede usar esta técnica también cuando trabaje con el código provisto por diferentes departamentos. Por ejemplo, el grupo de base de datos podría tener su propia prueba de unidad de caja blanca; sin embargo, también debe verificar que, desde una perspectiva de caja negra, los desencadenantes y restricciones se hayan programado correctamente al inspeccionar el resultado de las transacciones de la funcionalidad que está expuesta a usted..

Pon a prueba tus suposiciones

Las pruebas unitarias pueden ser una forma sencilla de reunir algunas pruebas con respecto a nuestras suposiciones acerca de una API. Tomemos el System.Drawing.Rectangle estructurar y probar algunas suposiciones aparentemente razonables sobre la implementación.

Supuestos del constructor de prueba

Hay dos Rectángulo constructores: uno que tiene Punto y tamaño parámetros, el otro tiene los parámetros x, y, ancho y altura. La documentación no indica si el tamaño (el ancho o el alto) debe ser positivo, así que escribamos una prueba para verificar que podemos construir un rectángulo con un ancho o alto negativo:

[TestMethod] public void RectangleNegativeSizeConstructorTest () Rectangle r = new Rectangle (0, 0, -4, -6);

Todo lo que estamos haciendo aquí en esta prueba es verificar que no se generan excepciones cuando construimos el rectángulo, y de hecho, este es el caso:

Rectangle Constructor Test

Supuestos de prueba con respecto a los valores de propiedad

Ahora probemos nuestras suposiciones acerca de ciertas propiedades. Las propiedades Parte superior, Izquierda, Fondo, y Derecha se describen como
http://msdn.microsoft.com/en-us/library/system.drawing.rectangle.aspx):

Superior: Obtiene la coordenada y del borde superior de esta estructura de rectángulo..

Izquierda: obtiene la coordenada x del borde izquierdo de esta estructura de Rectángulo.

Inferior: Obtiene la coordenada y que es la suma de los valores de las propiedades Y y Altura de esta estructura de rectángulo..

Derecha: Obtiene la coordenada x que es la suma de los valores de propiedad X y Ancho de esta estructura de rectángulo..

Entonces, con el rectángulo anterior, con un ancho y una altura negativos, y por lo tanto teniendo coordenadas [(-4, -6), (0, 0)], haríamos las siguientes suposiciones:

[TestMethod] public void TestLeft () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Left == -4, "Expected Left == -4 pero fue" + r.Left);  [TestMethod] public void TestTop () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Top == 0, "Expected Top == 0 pero fue" + r.Top);  [TestMethod] public void TestRight () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Right == 0, "Expected Right == 0 pero era" + r.Right);  [TestMethod] public void TestBottom () Rectangle r = new Rectangle (0, 0, -4, -6); Assert.IsTrue (r.Bottom == -6, "Expected Bottom == -6 pero fue" + r.Bottom);

Sin embargo, éste no es el caso:

Pruebas de suposiciones acerca de las propiedades del rectángulo

De hecho, la determinación de la parte superior e inferior también parece totalmente arbitraria, ya que he realizado pruebas en exactamente las mismas dimensiones del rectángulo y he observado diferentes resultados en el Parte superior y Fondo valores de propiedad.

Suposiciones de prueba sobre los resultados del método

La documentación de MSDN indica que la Rectangle.Intersect método:

Devuelve una tercera estructura de Rectángulo que representa la intersección de otras dos estructuras de Rectángulo.
Si no hay una intersección, se devuelve un rectángulo vacío.

Por lo tanto, podemos construir una prueba simple:

[TestMethod] public void TestIntersection () Rectangle r1 = new Rectangle (0, 0, 10, 10); Rectángulo r2 = nuevo Rectángulo (10, 10, 5, 5); Assert.IsFalse (r1.IntersectsWith (r2), "Se espera que R1 y R2 no se intersecten"); Assert.IsTrue (Rectangle.Intersect (r1, r2) == Rectangle.Empty, "Se esperaba un rectángulo de intersección vacío.");

con el resultado:

Probando nuestras suposiciones acerca de las devoluciones de métodos

Esto nos informa que nuestra expectativa, basada en la documentación, es incorrecta..

En conclusión

La prueba de unidad es una herramienta importante en el proceso de prueba. Si bien las pruebas de integración y usabilidad suelen estar más centradas en el cliente (informes, hitos, verificación de requisitos de alto nivel), las pruebas unitarias son la primera línea de defensa para un programador, su equipo y los gerentes de equipo. Si se usa con prudencia (recuerde, no pretende crear miles de luces verdes bonitas), puede ser una forma rentable de verificar la corrección computacional del código y para volver a crear errores y verificar que se hayan solucionado..

Sin embargo, las buenas prácticas de pruebas unitarias requieren un enfoque disciplinado, un compromiso con el tiempo y el esfuerzo necesarios para implementar y mantener las pruebas y, desde la perspectiva de un programador, también requieren buenas prácticas de programación y, a menudo, imponen decisiones arquitectónicas. Este último puede ir en contra de las restricciones de "solo hazlo" (lo que puede ser bastante legítimo), y potencialmente puede afectar el rendimiento. Por el lado positivo, las prácticas de programación y las arquitecturas que las pruebas unitarias obligan a usar son a menudo beneficiosas para todo el proceso de desarrollo de la aplicación, lo que reduce los costos y mejora la capacidad de mantenimiento, no porque el código sea probado por la unidad, sino porque el código está escrito mejor de modo que puede ser probado por la unidad.

Código