¿Cuáles son algunas convenciones de nomenclatura populares para las Pruebas unitarias? [cerrado]

Esto también vale la pena leerlo: Estructuración de Pruebas unitarias

La estructura tiene una clase de prueba por clase que se está probando. Eso no es tan inusual. Pero lo que era inusual para mí era que tenía una clase anidada para cada método que se estaba probando.

Por ejemplo

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

Y he aquí por qué:

Bueno, para empezar, es una buena manera de mantener las pruebas organizadas. Todos los las pruebas (o hechos) para un método se agrupan. Por ejemplo, si se utilizan las teclas CTRL + M, CTRL + O acceso directo a colapsar los cuerpos del método, puede escanee fácilmente sus pruebas y léalas como una especificación para su código.

También me gusta este enfoque:

MethodName_StateUnderTest_ExpectedBehavior

Así que tal vez ajustar a:

StateUnderTest_ExpectedBehavior

Porque cada prueba ya estará en una clase anidada

Tiendo a usar la convención de MethodName_DoesWhat_WhenTheseConditions así que por ejemplo:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Sin embargo, lo que veo mucho es hacer que el nombre de la prueba siga la estructura de pruebas unitarias de

• Organizar
• Act
• Assert

Que también sigue la sintaxis BDD / Gherkin de:

• Dado
• Cuando
• Entonces

Que sería nombrar la prueba de la manera de: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

Así que a su ejemplo:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Sin embargo hago mucho prefiera poner primero el nombre del método que se está probando, porque entonces las pruebas se pueden organizar alfabéticamente, o aparecer ordenadas alfabéticamente en el cuadro desplegable miembro en VisStudio, y todas las pruebas para 1 método se agrupan juntas.

En cualquier caso, me gusta separar las secciones mayores del nombre de la prueba con guiones bajos, en lugar de cada palabra , porque creo que hace que sea más fácil leer y transmitir el punto de la prueba.

En otras palabras, yo como: Sum_ThrowsException_WhenNegativeNumberAs1stParam mejor que Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Nombro mis métodos de prueba como otros métodos usando "PascalCasing" sin guiones bajos o separadores. Dejo la prueba postfix para el método, porque no agrega ningún valor. El atributo TestMethod indica que el método es un método de ensayo.

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

Debido al hecho de que cada clase de prueba solo debe probar otra clase, dejo el nombre de la clase fuera del nombre del método. El nombre de la clase que contiene los métodos de prueba se denomina como la clase bajo prueba con el postfix "Tests".

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

Para los métodos que prueban excepciones o acciones que no son posibles, prefijo el método de prueba con la palabra Cannot.

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

Mis convenciones de nombres se basan en el artículo "TDD Tips: Test Naming Conventions & Guidelines" de Bryan Cook. Encontré este artículo muy útil.

El primer conjunto de nombres es más legible para mí, ya que el camelCasing separa las palabras y las barras inferiores separan partes del esquema de nombres.

También tiendo a incluir "Test" en alguna parte, ya sea en el nombre de la función o en el espacio de nombres o clase que la encierra.

Mientras sigas una sola práctica, realmente no importa. Generalmente, escribo una sola prueba unitaria para un método que cubre todas las variaciones para un método (tengo métodos simples;) y luego escribo conjuntos más complejos de pruebas para los métodos que lo requieren. Por lo tanto, mi estructura de nombres es generalmente de prueba (un remanente de JUnit 3).

Utilizo un prefijo 'T' para los espacios de nombres de prueba, clases y métodos.

Intento ser ordenado y crear carpetas que replican los espacios de nombres, luego crear una carpeta de pruebas o un proyecto separado para las pruebas y replicar la estructura de producción para las pruebas básicas:

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

Puedo ver fácilmente que algo es una prueba, sé exactamente a qué código original pertenece, (si no puedes resolver eso, entonces la prueba es demasiado complicada de todos modos).

Se parece a las interfaces convención de nomenclatura, (quiero decir, no te confundes con las cosas que comienzan con 'I', ni lo harás con'T').

Es fácil simplemente compilar con o sin las pruebas.

Es bueno en teoría de todos modos, y funciona bastante bien para proyectos pequeños.