Como especificar parâmetros do método de teste com testdriven.net?

Question

Estou escrevendo testes de unidade com o NUNIT e o plug -in testdriven.net. Eu gostaria de fornecer parâmetros a um método de teste como este:

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

    ...
}

Como você pode ver, esses parâmetros são dados privados, por isso não quero codificá-los ou colocá-los em um arquivo. Na verdade, eu não quero escrevê -los qualquer lugar, Quero ser solicitado cada vez que executar o teste.

Quando tento executar este teste, recebo a seguinte mensagem na janela de saída:

Testcase 'myProject.mytests.testlogin' não executado: nenhum argumento foi fornecido

Então, minha pergunta é: como faço para fornecer esses parâmetros? Eu esperava que o testdriven.net exibisse um aviso para que eu pudesse inserir os valores, mas não ...

Desculpe se minha pergunta parece estúpida, a resposta provavelmente é muito simples, mas não consegui encontrar nada útil no Google ...

---

EDIT: Acabei de encontrar uma maneira de fazer isso, mas é um truque sujo ...

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

Ainda estou interessado em uma solução melhor ...

Answer 1

Os testes de unidade normalmente não devem fazer parâmetros. Você cria os dados necessários no próprio teste.

• O valor esperado
• Você chama seu método que deseja testar passando os argumentos necessários
• Você compara o resultado com o valor esperado e o valor retornado do seu método testado

Os testes de unidade MS não permitem a passagem dos parâmetros para os testes. Em vez disso, você precisa criar Testes de unidade de Datadriven. Experimente o link, pode ajudá -lo.

Conforme mencionei. Eu não declararia transmitir argumentos para a unidade testa uma boa prática.

---

Atualizar: Eu era jovem :). Considere a resposta de Sarfraz sobre como passar parâmetros para testes de NUNIT.

Answer 2

Use o Caso de teste atributo.

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

Answer 3

Eu acho que você pode resolver esse problema usando o plugin Rowtest para Nunit encontrado aqui http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/

Você pode criar testes simples orientados a dados, onde os dados de teste são fornecidos pelos atributos [da linha]. Então, aqui está um exemplo de teste que é executado repetidamente com parâmetros diferentes:

[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

Concordo com as outras respostas que os argumentos aprovados podem não ser as melhores práticas, mas nem credenciais de codificação ou endereços de servidor que podem mudar em algum momento.

Inspirado na solução sugerida em questão, simplesmente leio a entrada do console em vez de usar caixas de entrada. Os argumentos são salvos em um arquivo. Ao iniciar um teste, o arquivo é redirecionado e para ser lido a partir de alguma função de inicialização que deve ser chamada antes da execução de casos de teste.

nunit tests.dll < test.config

Isso evita a interação do usuário e deve ser executável por qualquer script de automação. A desvantagem é que a senha ainda precisa ser salva em algum lugar, mas pelo menos pode ser salva local na máquina dos testadores e é fácil de alterar.

Isso foi para um projeto, onde as folhas do Excel contendo os testes (não testes de unidade por definição) foram usadas para permitir que outras pessoas criem casos de teste para um projeto do lado do servidor maior sem alterar nenhum código. Teria sido ruim se todos os casos de teste tivessem que ser forçados em uma única planilha gigante do Excel. Também não havia IC, apenas muitos ambientes de teste em diferentes servidores.