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

Question

General

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

Ejemplos

1) Nombre del método_Estado bajo prueba_Comportamiento esperado

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Fuente: Estándares de nomenclatura para pruebas unitarias

2) Separar cada palabra mediante guión bajo

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

• Nombres de métodos finales con Prueba
• Iniciar nombres de métodos con nombre de clase

Answer 1

Estoy prácticamente contigo en este aspecto.Las convenciones de nomenclatura que ha utilizado son:

• Tener claro cuál 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 rayo No creo que el Prueba el prefijo es necesario.Es un código de prueba, lo sabemos.Si necesita hacer esto para identificar el código, entonces tiene problemas mayores. su código de prueba no debe confundirse con su código de producción.

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

Dicho esto, todavía soy bastante nuevo en las pruebas y blogueando mis aventuras con él :)

Answer 2

También vale la pena leer esto: Estructuración de pruebas unitarias

La estructura tiene una clase de prueba por cada clase que se está probando.Eso no es tan inusual.Pero lo que fue inusual para mí fue 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 he aquí por qué:

Bueno, para empezar, 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 acceso directo Ctrl+M, Ctrl+O para colapsar los cuerpos del método, puede escanear fácilmente sus pruebas y leerlas como una especificación para su código.

También me gusta este enfoque:

Nombre del método_EstadoUnderTest_Comportamiento esperado

Entonces tal vez ajuste a:

EstadoUnderTest_ExpectedBehavior

Porque cada prueba ya estará en una clase anidada.

Answer 3

Tiendo a usar la convención de MethodName_DoesWhat_WhenTheseConditions así 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

• Arreglar
• Acto
• Afirmar

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

• Dado
• Cuando
• Entonces

lo cual sería nombrar la prueba de la manera: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

entonces a tu ejemplo:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Sin embargo, prefiero poner primero el nombre del método que se está probando, porque entonces 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 los principales. secciones del nombre de la prueba con guiones bajos, a diferencia de cada palabra, porque creo que hace que sea más fácil de leer y transmitir el objetivo de la prueba.

En otras palabras, me gusta: Sum_ThrowsException_WhenNegativeNumberAs1stParam mejor que Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Answer 4

Nombro mis métodos de prueba como otros métodos usando "PascalCasing" sin guiones bajos ni separadores.les dejo el postfijo Prueba para el método de salida, porque no agrega ningún valor.Que el método es un método de prueba se indica mediante el atributo 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 denomina como la clase bajo prueba con el sufijo "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, prefijo 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 convención de nomenclatura se basa en el artículo. "Consejos TDD:Convenciones y pautas de nomenclatura de pruebas" de Bryan Cook.Encontré este artículo muy útil.

Answer 5

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

También tiendo a incluir "Prueba" en algún lugar, ya sea en el nombre de la función o en el espacio de nombres o clase adjunto.

Answer 6

Mientras sigas una única práctica, realmente no importa.Generalmente, escribo una prueba unitaria ú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 suele ser prueba (un vestigio de JUnit 3).

Answer 7

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

Intento ser ordenado y crear carpetas que repliquen los espacios de nombres, luego creo una carpeta de pruebas o un proyecto separado para las pruebas y replico 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 resolverlo, entonces la prueba es demasiado complicada de todos modos).

Se parece a la convención de nomenclatura de interfaces (quiero decir, no te confundirás con las cosas que comienzan con 'I', ni tampoco 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.