2010-05-06 10 views
6

Estas tres pruebas son idénticas, excepto que usan una función estática diferente para crear una instancia de StartInfo. Tengo este patrón que viene a través de mi código de prueba, y me encantaría para ser capaz de simplificar esto usando [TestCase], o de cualquier otra manera que reduzca el código repetitivo. A mi leal saber y entender, no tengo permitido usar un delegado como argumento [TestCase], y espero que las personas aquí tengan ideas creativas sobre cómo hacer que el código sea más conciso.¿Cómo simplifico estas pruebas de NUNit?

[Test] 
    public void ResponseHeadersWorkinPlatform1() 
    { 
     DoResponseHeadersWorkTest(Platform1StartInfo.CreateOneRunning); 
    } 
    [Test] 
    public void ResponseHeadersWorkinPlatform2() 
    { 
     DoResponseHeadersWorkTest(Platform2StartInfo.CreateOneRunning); 
    } 
    [Test] 
    public void ResponseHeadersWorkinPlatform3() 
    { 
     DoResponseHeadersWorkTest(Platform3StartInfo.CreateOneRunning); 
    } 

    void DoResponseHeadersWorkTest(Func<ScriptResource,StartInfo> startInfoCreator) 
    { 
     ScriptResource sr = ScriptResource.Default; 
     var process = startInfoCreator(sr).Start(); 
     //assert some things here 
    } 

Respuesta

8

En primer lugar, no creo que el original sea tan malo. Es complicado si sus afirmaciones son diferentes desde el caso de prueba hasta el caso de prueba.

De todos modos, puede usar un caso de prueba, pero no se puede hacer a través de un atributo estándar [TestCase] ​​debido al uso de tipos más complicados. En su lugar, debe usar un IEnumerable <> público como proveedor de datos y luego etiquetar su método de prueba con un atributo [TestCaseSource].

intentar algo como:

public IEnumerable<Func<ScriptResource, StartInfo>> TestCases 
    { 
     get 
     { 
      yield return Platform1StartInfo.CreateOneRunning; 
      yield return Platform2StartInfo.CreateOneRunning; 
      yield return Platform3StartInfo.CreateOneRunning; 
     } 
    } 

    [TestCaseSource("TestCases")] 
    public void MyDataDrivenTest(Func<ScriptResource, StartInfo> startInfoCreator) 
    { 
     ScriptResource sr = ScriptResource.Default; 
     var process = startInfoCreator(sr); 

     // do asserts 
    } 
} 

Ésta es una versión más concisa del patrón estándar de rendimiento casos TestCaseData que contienen los parámetros. Si cede instancias de TestCaseData, puede agregar más información y comportamientos a cada prueba (como excepciones esperadas, descripciones, etc.), pero es un poco más detallado.

Parte de la razón por la que realmente me gusta esto es que puedes hacer un método para tu "acto" y un método para tu "afirmación", luego mezclarlos y combinarlos de forma independiente. P.ej. mi amigo estaba haciendo algo ayer donde usó dos acciones para decir ("cuando se llama al método Blah, este método en el modelo de vista debe activarse"). Muy cortante y efectivo!

+1

me enseñó un nuevo concepto !!! más +1 – Prashant

+0

+1 agradable. Aquí hay un [enlace de documentación de NUnit mejorado con ejemplos] (http://nunit.org/index.php?p=testCaseSource&r=2.5.10). –

0

Se ve bien. ¿Estás buscando agregar una fábrica? O puede agregar estos métodos a una Lista de Acciones (en la configuración de prueba) y llamar al delegado de la primera acción, delegado de la segunda acción y delegado de la tercera acción.

Cuestiones relacionadas