¿Cómo especifico los parámetros del método de prueba con TestDriven.NET?

Question

Estoy escribiendo pruebas unitarias con NUnit y el plugin TestDriven.NET. 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 información privada, así que no quiero se codifican o ponerlos en un archivo. En realidad, no quiero escribirlos en cualquier parte, quiero que se me pregunte cada vez que ejecuto la prueba.

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

TestCase 'MyProject.MyTests.TestLogin' no ejecutadas: No se proporcionaron argumentos

Así mi pregunta es, ¿cómo proporciono estos parámetros? Esperaba que TestDriven.NET mostrara un mensaje para poder ingresar los valores, pero no ...

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

---

EDIT: 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. Crea los datos necesarios dentro de la prueba en sí.

• El valor esperado
• Usted llama a su método que desea probar pasando los argumentos necesarios
• se compara el resultado con el valor esperado y el valor devuelto por el método probado

EM Las pruebas unitarias no permiten el paso de parámetros a las pruebas. En su lugar, debe crear Datadriven Unit tests. Prueba el enlace, puede ayudarte.

Como mencioné. No declararía pasar argumentos a pruebas unitarias en sí una buena práctica.

---

Actualización: era joven :). Considere la respuesta de Sarfraz en lugar de cómo pasar los parámetros a las pruebas NUnit.

Answer 2

Creo que puede resolver este problema utilizando el complemento RowTest para NUnit que se encuentra aquí http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/

Puede crear pruebas simples controladas por datos donde los atributos [Row] proporcionan los datos de prueba. Así que aquí es 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 3

Utilice el atributo TestCase.

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

Answer 4

Estoy de acuerdo con las otras respuestas que pasan argumentos 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 leer la entrada de la consola en lugar de utilizar cuadros de entrada. Los argumentos se guardan en un archivo. Al iniciar las pruebas, el archivo se redirige y se debe leer desde alguna función de inicialización que se debe invocar antes de que se ejecute cualquier caso de prueba.

nunit tests.dll < test.config 

Esto evita la interacción del usuario y debe poder ejecutarse mediante cualquier secuencia de comandos de automatización. Lo malo es que la contraseña aún tiene que guardarse en alguna parte, pero al menos se puede guardar localmente en la máquina de prueba 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. Hubiera sido malo si todos los casos de prueba tuvieran que forzarse en una sola hoja gigante de Excel. Tampoco hubo IC, solo muchos entornos de prueba en diferentes servidores.