Quais são algumas convenções de nomenclatura populares para testes de unidade? [fechadas]

Question

Geral

• Siga as mesmas normas para todos os testes.
• Seja claro sobre o que cada estado de teste é.
• Seja específico sobre o comportamento esperado.

Exemplos

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Fonte: padrões de nomenclatura para testes de unidade

2) separando cada palavra por sublinhado

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

Outros

• nomes de métodos finais com Test
• Iniciar nomes de métodos com o nome da classe

Answer 1

Estou bastante com você neste homem um. As convenções de nomenclatura que você usou são:

• claro sobre o que cada estado teste é.
• específica sobre o comportamento esperado.

O que mais você precisa de um nome de teste?

Ao contrário da resposta de Ray Eu não acho que o teste prefixo é necessário. É o código de teste, nós sabemos disso. Se você precisa fazer isso para identificar o código, então você tem problemas maiores, seu código de teste não deve ser confundida com o seu código de produção.

Como para o comprimento ea utilização de sublinhado, o seu código de teste , quem se importa? Só você e sua equipe vai vê-lo, desde que seja legível e claro sobre o que o teste está fazendo, continue! :)

Dito isto, eu ainda sou muito novo para testar e blogs minhas aventuras com ele :)

Answer 2

Esta é também uma leitura vale a pena: Estruturação Unidade de Testes

A estrutura tem uma classe de teste por classe a ser testado. Isso não é tão incomum. Mas o que era incomum para mim era que ele tinha uma classe aninhada para cada método que está sendo testado.

por exemplo.

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

E aqui está o porquê:

Bem para uma coisa, é uma boa maneira de manter provas organizadas. Todos testes (ou fatos) para um método são agrupados em conjunto. Por exemplo, se você usar o CTRL + M, CTRL + O atalho para recolher corpos método, você pode digitalizar facilmente seus testes e lê-los como uma especificação para seu código.

Eu também gosto desta abordagem:

MethodName_StateUnderTest_ExpectedBehavior

Assim, talvez ajustar-se:

StateUnderTest_ExpectedBehavior

Porque cada teste já estará em uma classe aninhada

Answer 3

I tendem a usar a convenção de MethodName_DoesWhat_WhenTheseConditions assim, por exemplo:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

No entanto, o que eu vejo um monte é fazer com que o nome do teste seguir a estrutura de teste de unidade de

• Organizar
• Act
• Assert

O que também segue a sintaxe BDD / Gherkin de:

• Dada
• Quando
• Em seguida

que seria para nomear o teste na forma de: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

de modo a seu exemplo:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

No entanto, eu prefiro muito mais colocando o nome do método que está sendo testado em primeiro lugar, porque então os testes podem ser organizados em ordem alfabética, ou aparecem por ordem alfabética na caixa de membro pendente na VisStudio, e todos os testes para um método são agrupados.

---

Em qualquer caso, eu gosto de separar o grande seções do nome do teste com sublinhados, ao contrário de todos os palavra , porque eu acho que torna mais fácil de ler e chegar ao ponto do teste de diâmetro.

Em outras palavras, eu gosto:. Sum_ThrowsException_WhenNegativeNumberAs1stParam melhor do que Sum_Throws_Exception_When_Negative_Number_As_1st_Param

Answer 4

Eu faço o meu nome métodos de ensaio como outros métodos usando "PascalCasing" sem quaisquer sublinhados ou separadores. Deixo o postfix Test para o fora método, porque ele não agrega valor. Que o método é um método de teste é indicado pelo atributo TestMethod .

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

Devido ao fato de que cada classe de teste só deve testar uma outra classe i deixar o nome da classe para fora do nome do método. O nome da classe que contém os métodos de teste é nomeado como a classe em teste com o sufixo "testes".

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

Para os métodos que o teste para exceções ou ações que não são possíveis, eu prefixar o método de ensaio com a palavra não pode .

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

A minha nomeação convension são base sobre o artigo "TDD Sugestões: teste Convenções de nomenclatura e Diretrizes " de Bryan Cook. Eu encontrei este artigo muito útil.

Answer 5

O primeiro conjunto de nomes é mais legível para mim, já que os separa CamelCasing palavras e as barras inferiores separar partes do esquema de nomeação.

Eu também tendem a incluir em algum lugar "Test", seja no nome da função ou o namespace anexando ou classe.

Answer 6

Enquanto você seguir uma única prática, isso realmente não importa. Geralmente, eu escrever um único teste de unidade para um método que abrange todas as variações para um método (I têm métodos simples;) e, em seguida, conjuntos de gravação mais complexos de testes para métodos que exijam. Meu estrutura de nomenclatura é, portanto, geralmente de teste (um resquício JUnit 3).

Answer 7

Eu uso um 'T' prefixo para namespaces de teste, classes e métodos.

Eu tento ser limpo e criar pastas que replicam os namespaces, em seguida, criar uma testes pasta ou separados projeto para os testes e replicar a estrutura de produção para os testes básicos:

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

Eu posso facilmente ver que algo é um teste, eu sei exatamente o código original se refere a, (se você não pode resolver isso, então o teste é muito complicado de qualquer maneira).

Parece assim como as interfaces convenção de nomenclatura, (quero dizer, você não ficar confuso com as coisas que começam com 'I', nem que você com 'T').

É fácil apenas compilar com ou sem os testes.

É bom na teoria de qualquer maneira, e funciona muito bem para pequenos projetos.