Hay muchas opciones más allá del báscico atributo [Test]. Esta sección describe brevemente estas opeciones.
Description
Este atributo permie agregar una descripción al test, el que aparecerá en la salida en texto y en xml.
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
// A Test with a Description
[Test(Description="This was written by Homer to test the Iliad.")]
public void TestWithDescription()
{
Console.WriteLine("Test with description");
}
}
}
Category
A veces es útil categorizar un Test. Esto se puede hacer con el atributo Category. Dentro de la interfaz de usuario de Zanebug GUI, esto le permitira aplicar filtros, ordenar, etc, por categoría.
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
// A Test with a Category
[Test(Category="Some Category")]
public void TestWithCategory()
{
Console.WriteLine("Test with category");
}
}
}
Ambos, TestFixtures y Tests pueden tener codigo de preparación que se puede ejecutar al comienzo y al final de sus iteraciones. Esto es útils en instancias donde usted necesite inicializar información en una base de datos, preparar un recurso, etc. y luego restarurar todo al estado previo después de que se ha ejecutado el test. Un ejemplo típico puede ser el siguiente escenario:
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
// Runs once at the beginning of the TestFixture
[TestFixtureSetUp]
public void TestFixtureSetUp()
{
// inserta registro de prueba en la base de datos
}
// A Test
[Test]
public void SimpleTest()
{
// código de prueba
}
// Runs once at the end of the TestFixture
[TestFixtureTearDown]
public void TestFixtureTearDown()
{
// borra los datos de la base datos
}
}
}
En el ejemplo anterior, las operaciones setup y teardown son ejecutadas cada vez que el TestFixture se ejecute. Lo mismo puede ser hecho a nivel del Test. Es aún posible ejecutar las operaciones run y teardown sólo en Tests específicos.
A continuación listamos los distintos atributos para setup y teardown:
Setup
TestFixtureSetUp
TestSetUp
SetUp (igual a TestSetUp - se provee para ser compatible con NUnit)
TearDown
TestFixtureTearDown
TestTearDown
TearDown (igual que TestTearDown - se provee para ser compatible con NUnit)
Vea la API para una documentación más completa.
Test Specific SetUp and Teardown
Cuando una operación SetUp o TearDown debe ser eejecutada para un teste especifico, entonces la propiedad Test debe ser usada:
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
// Runs once at the beginning of SimpleTest only
[TestSetUp("SimpleTest")]
public void SpecificTestSetUp()
{
// código de setup
}
// A Test
[Test]
public void SimpleTest()
{
// código de test
}
// Se ejecuta solo una vez al final de SimpleTest solamente
[TestTearDown("SimpleTest")]
public void SpecificTestTearDown()
{
// código teardown
}
}
}
A menudo los tests se escriben esperando que ocurra una excepción. Por ejemplo, si usted tiene un método llamado Divide(int a, int b), y pasa un 0 como el parametro b, entonces se esperaría que se produzca una excepción del tipo DivideByZeroException. Con pruebas adecuadas se validará que este error se produzca. Para lograr esto, el atributo ExpectedException debería ser usado:
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
[Test]
[ExpectedException(typeof(DivideByZeroException))]
public void ExpectedDivideByZeroException()
{
MyMath.Divide(12,0); // produce una DivideByZeroException
}
}
}
En el ejemplo anterior, el Test espera que se produzca una excepción DivideByZeroException. Si la excepción se produce, el test pasa, sino, entonces el test falla.
El test pasara si la excepción esperada se produce, o una excepción que hereda de esta (es decir, una clase hija). POr ejemplo, si en el ejemplo anterior se esperara una excepción del tipo Exception, entonces el Test todavía pasara ya que DivideByZeroException es una subclase de Exception.
Es posible ignorar test en tiempo de ejecución. Por ejemplo, puede tener un test que sea muy largo y extensivo en el uso de recursos y en tiempo de ejecución, que sólo le necesite correr ocasionalmente. Usted puede marcar ese Test con el atributo Ignore y este no se ejecutará. Si quiere ejecutarlo más tarde, basta que retire el atributo. Usted puede agregar una razón porque el test esta siendo ignorado, lo que sera desplegado en tiempo de ejecución.
Dentro de la interfaz de Zanebug, usted puede invalidar el atributo Ignore seleccionando un Test. Cuando un TestSuite se carga primero, todos los Tests marcados, con Ignore, no estaran marcados. Ellos pueden ser chequeados en cualquier moment en que usted decida ejecutarlos. De todas maneras usted puede imponer el atributo Ignore en los Tests en ejecución deseleccionándolos en la interfaz de usuario.
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
[Test]
[Ignore]
public void SimpleTest1()
{
//test code
}
[Test]
[Ignore("Some reason")]
public void SimpleTest2()
{
//test code
}
}
}
Cuando se requiere que una operación solo consuma una cierta cantidad de memoria, entonces el atributo MaxKMemory se debe usar. Este especifica cuanta memoria debería ser usada, y cualquier exceso provocara la falla.
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
[Test]
[MaxKMemory(200)]
public void SimpleTest()
{
//test code
//if this test consumes more than 200kb of memory
//then it will fail
}
}
}
Esta es una característica en Beta en este momento, y no se garantiza que se desempeñe adecuadamente (se han notado discrepancias en la medida del uso de memoria)
Los tests basados en el desempeño, a menudo miden la velocidad a la cual ocurren las operaciones. Cuando es necesario asegurar un cierto nivel de desempeño, se debería usar el atributo MinOperationsPerSecond.
El motor de Zanebug mide el tiempo de ejecución para un test, y determina cuanto tiempo consume un tests en correr en un segundo.
El motor de prueba, introduce una pequeño cantidad de sobrecarga, via Reflexión, lo cual debe ser tomado en cuenta.
Debido a la sobre carga de la inicialización, el Test siempre se ejecutará más lento la primera vez. Por lo tanto, se recomiend que un Test sea ejecutado más de una vez despues de ser cargado, para tener una mejor idea de su desempeño.
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
// A Test that will fail if it can't be repeated
// the min number of times in a second
[Test]
[MinOperationsPerSecond(1000)]
public void MinOperationsPerSecond()
{
// if this test can not be repeated 1000 times within a second
// it fails
}
}
}Las pruebas se deben repetir a menudo en la sucesión para medir cosas tales como funcionamiento, ediciones de la concurrencia, etc medios. Esto se puede lograr con la cualidad de la repetición
using System;
using Adapdev.UnitTest;
namespace Examples.Zanebug
{
[TestFixture]
public class Attributes
{
// A Test that is repeated a set number of times
[Test]
[Repeat(5)]
public void Repeat()
{
// test code
}
// A Test that is repeated a set number of times
// with a 3 second delay in between
[Test]
[Repeat(5,3000)]
public void RepeatWithDelay()
{
// test code
}
}
}