Come faccio a specificare i parametri del metodo di prova con TestDriven.NET?

Question

Sto scrittura di unit test con NUnit e il plugin TestDriven.NET. Mi piacerebbe per fornire i parametri ad un metodo di prova in questo modo:

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

    ...
}

Come si può vedere, questi parametri sono dati privati, in modo da non vogliono hard-code loro o metterli in un file. In realtà non voglio scrivere di loro ovunque , voglio essere richiesto ogni volta che ho eseguito il test.

Quando si tenta di eseguire questo test, ho il seguente messaggio nella finestra di output:

  

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

Quindi la mia domanda è: come faccio a fornire questi parametri? Mi aspettavo TestDriven.NET per visualizzare un prompt in modo che io possa inserire i valori, ma non ha ...

Scusate se la mia domanda sembra stupida, la risposta è probabilmente molto semplice, ma non ho trovato nulla di 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 dovrebbero di norma non prendere alcun parametro. È possibile creare i dati necessari all'interno della prova stessa.

• 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

test MS unità non consentono il passaggio di parametri di test. Invece è necessario creare Datadriven Unità test . Provare il collegamento, può aiutare.

Come ho già detto. Non vorrei dichiarare passaggio di argomenti per unità di test si buone pratiche.

---

Aggiornamento: ero giovane :). Prendere in considerazione la risposta di Sarfraz invece su come passare parametri a test NUnit.

Answer 2

Utilizzare l'attributo TestCase .

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

Answer 3

Penso che si possa risolvere questo problema utilizzando il plugin RowTest per NUnit trovato qui http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/

È possibile creare semplici test data-driven in cui i dati di prova è fornita da [Linea] attributi. Quindi, ecco un esempio di un test che viene eseguito più e più volte 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 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 proposta in questione, ho semplicemente letto console di input invece di utilizzare caselle di input. Gli argomenti vengono salvati in un file. Quando si avvia una delle prove, il file viene reindirizzato e che deve essere letto da qualche funzione di inizializzazione che dovrebbe essere chiamato prima di eventuali casi di test eseguiti.

nunit tests.dll < test.config

Questo evita interazione con l'utente e dovrebbe essere eseguibile da qualsiasi script di automazione. Unico inconveniente è che la password deve ancora essere salvato da qualche parte, ma almeno può essere salvato locale sulla macchina tester ed è facile da cambiare.

Questa è stata per un progetto, in cui eccelle fogli contenenti i test (non unit test per definizione) sono stati usati per lasciare che gli altri creare casi di test per un progetto più grande lato server senza modificare il codice. Sarebbe stato male se tutti i casi di test dovevano essere costretto in un unico gigantesco foglio di Excel. Inoltre non c'era CI, a molti ambienti di test su server diversi.