Come si specificano i parametri del metodo di prova con TestDriven.NET?

Question

Sto scrivendo unit test con NUnit e il plugin TestDriven.NET. Mi piacerebbe per fornire i parametri ad un metodo di test come questo:

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

    ... 
} 

Come si può vedere, questi parametri sono dati privati, quindi non voglio loro hard-code o metterli in un file. In realtà non voglio scriverli ovunque, voglio essere richiesto ogni volta che eseguo il test.

Quando provo ad eseguire questo test, ottengo il seguente messaggio nella finestra di output:

TestCase 'MyProject.MyTests.TestLogin' non eseguite: Non sono argomenti sono stati forniti

Così la mia domanda è, come posso fornire questi parametri? Mi aspettavo TestDriven.NET per visualizzare un prompt in modo che possa immettere i valori, ma non ...

Scusa se la mia domanda sembra stupida, la risposta è probabilmente molto semplice, ma non ho trovato nulla utile su Google ...

---

EDIT: ho appena trovato un modo per farlo, ma è un brutto scherzo ...

[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 } 
      }; 
     } 
    } 

sono ancora interessato a una soluzione migliore ..

Answer 1

unit test non dovrebbero normalmente accetta parametri. Si creano i dati necessari all'interno del test stesso.

• Il valore atteso
• Si chiama il metodo che si desidera testare passando gli argomenti necessari
• si confronta il risultato con il valore atteso e il valore restituito dal metodo collaudato

MS I test unitari non consentono il passaggio dei parametri ai test. Invece è necessario creare Datadriven Unit tests. Prova il link, potrebbe aiutarti.

Come ho detto. Non dichiarerei di passare argomenti a prove unitarie di per sé buone pratiche.

---

Aggiornamento: ero giovane :). Considera la risposta di Sarfraz invece su come passare i parametri ai test NUnit.

Answer 2

Penso che tu può risolvere questo problema utilizzando il plug-in RowTest per NUnit trovato qui http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/

È possibile creare semplici test basati sui dati in cui i dati di test sono forniti dagli attributi [Row]. Così qui è un esempio di un test che viene eseguito ripetutamente con diversi parametri:

[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

Utilizzare l'attributo TestCase.

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

Answer 4

Sono d'accordo con le altre risposte che il passaggio di argomenti potrebbero non essere le migliori pratiche, ma nessuno dei due è difficile codifica credenziali o gli indirizzi dei server che possono cambiare a un certo punto.

Ispirato alla soluzione suggerita in questione, ho semplicemente letto l'input della console anziché utilizzare le caselle di input. Gli argomenti sono salvati in un file. Quando si avvia un test, il file viene reindirizzato e viene letto da una funzione di inizializzazione che deve essere richiamata prima dell'esecuzione di qualsiasi caso di test.

nunit tests.dll < test.config 

Ciò evita l'interazione dell'utente e dovrebbe essere eseguibile da qualsiasi script di automazione. Il rovescio della medaglia è che la password deve ancora essere salvata da qualche parte, ma almeno può essere salvata localmente sulla macchina tester ed è facile da cambiare.

Questo era per un progetto, in cui sono stati utilizzati fogli Excel contenenti i test (non test unitari per definizione) per consentire agli altri di creare casi di test per un progetto lato server più grande senza modificare alcun codice. Sarebbe stato male se tutti i casi di test dovessero essere forzati in un unico foglio gigante. Inoltre non esisteva un CI, solo molti ambienti di test su server diversi.