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

Geral

• Siga os mesmos padrões 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: Nomeação de padrões 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 ()

De outros

• Terminar nomes de métodos com Teste
• Iniciar nomes de métodos com o nome da classe

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

• Claro sobre o que é cada estado de teste.
• Específico sobre o comportamento esperado.

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

Ao contrário da resposta de Ray, não acho que o prefixo Teste seja necessário. É um código de teste, nós sabemos disso. Se você precisar fazer isso para identificar o código, terá problemas maiores; o código de teste não deve ser misturado ao código de produção.

Quanto ao tamanho e uso do sublinhado, seu código de teste , quem se importa? Somente você e sua equipe verão isso, desde que seja legível e claro sobre o que o teste está fazendo, continue! :)

Dito isto, ainda sou bastante novo para testar e postar minhas aventuras no blog com ele :)

Também vale a pena ler: Estruturar testes de unidade

A estrutura possui uma classe de teste por classe que está sendo testada. Isso não é tão incomum. Mas o que era incomum para mim era que ele tinha uma classe aninhada para cada método 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, por um lado, é uma ótima maneira de manter os testes organizados. Todos os testes (ou fatos) de um método são agrupados. Por exemplo, se você usar o atalho CTRL + M, CTRL + O para recolher os corpos dos métodos, poderá digitalizar facilmente seus testes e lê-los como uma especificação para o seu código.

Eu também gosto dessa abordagem:

MethodName_StateUnderTest_ExpectedBehavior

Então, talvez se ajuste a:

StateUnderTest_ExpectedBehavior

Porque cada teste já estará em uma classe aninhada

Costumo usar a convenção de MethodName_DoesWhat_WhenTheseConditions, por exemplo:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

No entanto, o que vejo muito é fazer com que o nome do teste siga a estrutura de teste da unidade de

• Organizar
• Aja
• Afirmar

Que também segue a sintaxe BDD / Gherkin de:

• Dado
• Quando
• Então

que seria nomear o teste da seguinte maneira: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

Então, para o seu exemplo:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

No entanto, prefiro colocar o nome do método que está sendo testado primeiro, porque os testes podem ser organizados em ordem alfabética ou exibidos em ordem alfabética na caixa suspensa do membro no VisStudio, e todos os testes para 1 método são agrupados.

De qualquer forma, gosto de separar as principais seções do nome do teste com sublinhados, em vez de todas as palavras , porque acho que facilita a leitura e a compreensão do ponto do teste.

Em outras palavras, eu gosto: Sum_ThrowsException_WhenNegativeNumberAs1stParammelhor que Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Eu nomeio meus métodos de teste como outros métodos usando "PascalCasing" sem sublinhados ou separadores. Deixo o teste postfix para o método de fora, porque ele não agrega valor. O fato de o método ser 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 deve testar apenas uma outra classe, deixo o nome da classe 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 postfix "Tests".

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

Para métodos que testam exceções ou ações que não são possíveis, prefixo o método de teste com a palavra Não é possível .

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

Minha convenção de nomenclatura é baseada no artigo "Dicas para TDD: convenções e diretrizes de nomenclatura de teste" de Bryan Cook. Achei este artigo muito útil.

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

Eu também tendem a incluir "Test" em algum lugar, no nome da função ou no espaço para nome ou classe anexa.

Contanto que você siga uma única prática, isso realmente não importa. Geralmente, escrevo um único teste de unidade para um método que cubra todas as variações de um método (tenho métodos simples;) e depois escrevo conjuntos de testes mais complexos para os métodos que o exigem. Minha estrutura de nomenclatura é, portanto, geralmente testada (uma retração do JUnit 3).

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

Tento ser limpo e criar pastas que replicam os espaços para nome, em seguida, crio uma pasta de testes ou um projeto separado para os testes e replico a estrutura de produção para os testes básicos:

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

Percebo facilmente que algo é um teste, sei exatamente a que código original ele se refere (se você não consegue resolver isso, o teste é complicado demais).

Parece com a convenção de nomenclatura de interfaces (quero dizer, você não se confunde com as coisas que começam com 'I', nem com 'T').

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

De qualquer forma, é bom em teoria e funciona muito bem para pequenos projetos.