¿Cómo puedo especificar el método de prueba de los parámetros con TestDriven.NET?

Question

Estoy escribiendo unidad de pruebas con NUnit y la TestDriven.NET en el complemento.Me gustaría proporcionar parámetros a un método de prueba como esta :

[TestFixture]
public class MyTests
{
    [Test]
    public void TestLogin(string userName, string password)
    {
        // ...
    }

    ...
}

Como se puede ver, estos parámetros son datos privados, por lo que no desea codificar ellos o ponerlos en un archivo.En realidad no quiero escribir de ellos en cualquier lugar, Quiero que se le pregunte cada vez que ejecute la prueba.

Cuando intento ejecutar esta prueba, me sale el siguiente mensaje en la ventana de salida :

La Prueba 'Miproyecto.MyTests.TestLogin' no se ejecuta:Sin argumentos fueron proporcionados

Así que mi pregunta es, ¿cómo puedo proporcionar estos parámetros ?Yo esperaba TestDriven.NET para mostrar un mensaje para que yo pueda entrar los valores, pero no...

Lo siento si mi pregunta parece estúpida, la respuesta es, probablemente, muy simple, pero no pude encontrar nada útil en Google...

---

EDITAR:Acabo de encontrar una manera de hacerlo, pero es un truco sucio...

    [Test, TestCaseSource("PromptCredentials")]
    public void TestLogin(string userName, string password)
    {
        // ...
    }

    static object[] PromptCredentials
    {
        get
        {
            string userName = Interaction.InputBox("Enter user name", "Test parameters", "", -1, -1);
            string password = Interaction.InputBox("Enter password", "Test parameters", "", -1, -1);
            return new object[]
            {
                new object[] { userName, password }
            };
        }
    }

Todavía estoy interesado en una solución mejor...

Answer 1

pruebas unitarias normalmente no deberían tener ningún parámetro. Para crear los datos necesarios dentro de la propia prueba.

• El valor esperado
• Usted llama a su método que desea probar pasando los argumentos necesarios
• Se trata de comparar el resultado con el valor esperado y el valor devuelto por el método de prueba

pruebas MS Unidad no permiten el paso de parámetros a pruebas. En su lugar es necesario crear Unidad basadas en datos prueba. Probar el enlace, puede ayudarle.

Como ya he mencionado. Yo no declarar pasar argumentos a sí mismo las pruebas unitarias de buenas prácticas.

---

Actualización: :) yo era joven. Considere la respuesta de Sarfraz en cambio en la forma de pasar parámetros a pruebas NUnit.

Answer 2

Utilice el atributo TestCase .

[TestCase("User1", "")]
[TestCase("", "Pass123")]
[TestCase("xxxxxx", "xxxxxx")]
public void TestLogin(string userName, string password)
{
    // ...
}

Answer 3

Creo que se puede resolver este problema mediante el uso de la RowTest plugin para NUnit encontrar aquí http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/

Usted puede crear una simple basado en Datos de Pruebas donde los datos de prueba proporcionados por [Fila] atributos.Así que aquí está un ejemplo de una prueba que se ejecuta una y otra vez con diferentes parámetros:

[TestFixture]
public class RowTestSample
{
 [RowTest]
 [Row( 1000, 10, 100.0000)]
 [Row(-1000, 10, -100.0000)]
 [Row( 1000, 7, 142.85715)]
 [Row( 1000, 0.00001, 100000000)]
 [Row(4195835, 3145729, 1.3338196)]
 public void DivisionTest(double numerator, double denominator, double result)
 {
    Assert.AreEqual(result, numerator / denominator, 0.00001);
 }
} 

Answer 4

Estoy de acuerdo con las otras respuestas que los argumentos que pasan pueden no ser las mejores prácticas, pero tampoco es difícil credenciales o direcciones de servidor que pueden cambiar en algún momento de codificación.

Inspirado por la solución propuesta en cuestión, simplemente leído entrada de la consola en lugar de utilizar cuadros de entrada. Los argumentos se guardan en un archivo. Cuando se inicia una de las pruebas, el archivo se redirige y para ser leído desde una cierta función de inicialización que debe ser llamado antes de que los casos de prueba se ejecutan.

nunit tests.dll < test.config

Esto evita la interacción del usuario y debe ser ejecutable por cualquier secuencia de comandos de automatización. Inconveniente es que la contraseña todavía tiene que ser guardado en alguna parte, pero al menos se puede guardar en la máquina local de probadores y es fácil de cambiar.

Esto era para un proyecto, donde sobresalen las hojas que contienen las pruebas (no pruebas unitarias, por definición) se utilizaron para que los demás crean casos de prueba para un proyecto del lado del servidor más grande sin cambiar ningún código. Habría sido malo si todos los casos de prueba tuvieron que ser forzado en un solo gigante hoja de Excel. Además no había CI, a muchos entornos de prueba en diferentes servidores.