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

General

• Siga los mismos estándares para todas las pruebas.
• Sea claro sobre cada estado de prueba.
• Sea específico sobre el comportamiento esperado.

Ejemplos

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Fuente: estándares de denominación para pruebas unitarias

2) Separar cada palabra por subrayado

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 ()

Otro

• Finalizar nombres de métodos con Test
• Nombre de método de inicio con nombre de clase

Estoy bastante contigo en este hombre. Las convenciones de nomenclatura que ha utilizado son:

• Claro sobre qué es cada estado de prueba.
• Específico sobre el comportamiento esperado.

¿Qué más necesitas de un nombre de prueba?

Contrariamente a la respuesta de Ray, no creo que sea necesario el prefijo Test . Es un código de prueba, lo sabemos. Si necesita hacer esto para identificar el código, entonces tiene mayores problemas, su código de prueba no debe mezclarse con su código de producción.

En cuanto a la longitud y el uso del guión bajo, su código de prueba , ¿a quién diablos le importa? Solo usted y su equipo lo verán, siempre que sea legible y tenga claro lo que está haciendo la prueba, ¡continúe! :)

Dicho esto, todavía soy bastante nuevo en probar y bloguear mis aventuras con él :)

También vale la pena leerlo: Pruebas de unidades de estructuración

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.

p.ej

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 aquí está el por qué:

Bueno, por un lado, es una buena manera de mantener las pruebas organizadas. Todas las pruebas (o hechos) para un método se agrupan. Por ejemplo, si usa el atajo CTRL + M, CTRL + O para colapsar los cuerpos de los métodos, puede escanear fácilmente sus pruebas y leerlas como una especificación para su código.

También me gusta este enfoque:

MethodName_StateUnderTest_ExpectedBehavior

Entonces tal vez ajustarse a:

StateUnderTest_ExpectedBehavior

Porque cada prueba ya estará en una clase anidada

Tiendo a usar la convención de MethodName_DoesWhat_WhenTheseConditionsmodo que, por ejemplo:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Sin embargo, lo que sí veo mucho es hacer que el nombre de la prueba siga la estructura de prueba unitaria de

• Organizar
• Actuar
• Afirmar

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

• Dado
• Cuando
• Luego

que sería nombrar la prueba de la siguiente manera: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

así que a tu ejemplo:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Sin embargo, prefiero poner primero el nombre del método que se está probando, porque luego las pruebas se pueden ordenar alfabéticamente o aparecer ordenadas alfabéticamente en el cuadro desplegable de miembros en VisStudio, y todas las pruebas para 1 método se agrupan.

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

En otras palabras, me gusta: Sum_ThrowsException_WhenNegativeNumberAs1stParammejor que Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

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

[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 nombra como la clase bajo prueba con el postfix "Pruebas".

[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, prefiero el método de prueba con la palabra No puedo .

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

Mi convección de nomenclatura se basa en el artículo "Consejos TDD: Convenciones y pautas de nomenclatura de prueba" de Bryan Cook. Encontré este artículo muy útil.

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

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

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

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

Intento ser ordenado y crear carpetas que replican los espacios de nombres, luego creo 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 puede resolverlo, entonces la prueba es demasiado complicada de todos modos).

Se parece a la convención de nomenclatura de interfaces (quiero decir, no se confunde con las cosas que comienzan con 'I', ni con 'T').

Es fácil compilar con o sin las pruebas.

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