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

General

  • Siga los mismos estándares para todas las pruebas.
  • Sea claro acerca de lo que es cada estado de prueba.
  • Sé 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 ()

Source: Naming standards for Unit Tests

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

  • End method names with Test
  • Start method names with class name
0
agregado editado
Puntos de vista: 1
agregado el autor Wedge, fuente

7 Respuestas

Estoy más o menos con usted en este hombre. Las convenciones de nomenclatura que ha usado son:

  • Desactive lo que es cada estado de prueba.
  • Específico sobre el comportamiento esperado.

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

Contrary to Ray's answer I don't think the Test prefix is necessary. It's test code, we know that. If you need to do this to identify the code, then you have bigger problems, your test code should not be mixed up with your production code.

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

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

0
agregado
Un argumento adicional para el prefijo. Cuando busca un archivo en IDE, puede buscar fácilmente casos de prueba comenzando con Test y su nombre de clase. Si el nombre de la clase y el nombre de la clase de prueba es el mismo, siempre tendremos que pausar y leer la ruta de dos archivos
agregado el autor THIS USER NEEDS HELP, fuente
Ligera contradicción "siempre que sea legible y clara" y "a quién ... le importa". Bueno, a todos nos importa cuando no es legible y claro, por eso es importante. :-)
agregado el autor David Victor, fuente

Nombro mis métodos de prueba como otros métodos usando "PascalCasing" sin guiones bajos o separadores. Dejo el postfix Test para el método, porque no agrega ningún valor. El método 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 debería 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 postfijo "Pruebas".

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

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

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

My naming convension are base on the article "TDD Tips: Test Naming Conventions & Guidelines" of Bryan Cook. I found this article very helpful.

0
agregado
No me gusta porque no incluye el comportamiento esperado
agregado el autor Johannes Rudolph, fuente
+1 para el enlace a mi publicación, aunque no es necesario usar un prefijo de "Prueba" en sus Pruebas. Asegúrese de que sus pruebas especifiquen el comportamiento esperado. Por ejemplo, CanRetrieveProperCountWhenAddingMultipleItems ()
agregado el autor bryanbcook, fuente

This is also worth a read: Structuring Unit Tests

La estructura tiene una clase de prueba por clase que se prueba. 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 porqué:

Bueno, para empezar, es una buena forma de organizar las pruebas. Todos   las pruebas (o hechos) para un método se agrupan juntas. Por ejemplo, si   utiliza el atajo CTRL + M, CTRL + O para colapsar cuerpos de 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

Entonces tal vez se ajuste a:

StateUnderTest_ExpectedBehavior

Porque cada prueba ya estará en una clase anidada

0
agregado
Para aquellos que usan el corrector de prueba de Resharper en Visual Studio, corrigieron los errores utilizando clases de prueba anidadas en 8.x. Desde entonces, esta se convirtió en mi estructura preferida por lejos.
agregado el autor angularsen, fuente

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

Sum_ThrowsException_WhenNegativeNumberAs1stParam

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

  • Organizar
  • Actuar
  • Afirmar

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

  • Dado
  • Cuando
  • Entonces

which would be to name the test in the manner of: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

para tu ejemplo:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Sin embargo, prefiero poner primero el nombre del método que se prueba, porque luego las pruebas pueden ordenarse 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 juntas.


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

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

0
agregado

Mientras sigas una sola práctica, en realidad no importa. En general, escribo una prueba unitaria para un método que cubre todas las variaciones de 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 suele ser prueba (un remanente de JUnit 3).

0
agregado

El primer conjunto de nombres es más legible para mí, ya que CamelCasing separa las palabras y las barras inferiores partes separadas 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 adjunto.

0
agregado
@Frank methodName = camelCase MethodName = PascalCase
agregado el autor Metro Smurf, fuente
@ metro-smurf: distinción interesante, nunca escuché el término PascalCase, y lo he estado haciendo durante mucho tiempo. Solo veo que el término PascalCase aparece en los círculos de desarrolladores de Microsoft, ¿es eso lo que haces?
agregado el autor Frank Szczerba, fuente
Historia de la carcasa de Pascal y Camel Case (de: Brad Abrams - blogs .msdn.com/brada/archive/2004/02/03/67024.aspx ) ... "En el diseño inicial del Framework tuvimos cientos de horas de debate sobre el estilo de nombramiento. Para facilitar estos debates, acuñó una serie de términos. Con Anders Heilsberg (el diseñador original de Turbo Pascal) un miembro clave del equipo de diseño, no es de extrañar que hayamos elegido el término Pascal Casing para el estilo de carcasa popularizado por el lengua
agregado el autor Heliac, fuente

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

Intento ser ordenado y crear carpetas que repliquen los espacios de nombres, luego crear una carpeta de pruebas o un proyecto separado para las pruebas y reproducir 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 muy complicada de todos modos).

Se parece a la convención de nomenclatura de interfaces (es decir, no te confundes con cosas que comienzan con 'I', ni con 'T').

Es fácil compilar con o sin las pruebas.

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

0
agregado
Demasiado húngaro (notación) para mí. Además, ad stung indicó que el prefijo T se usa para los parámetros de tipo genérico.
agregado el autor Danny Varod, fuente
Acepto, la notación húngara se ha visto privada de contenido y, debido al conflicto con los parámetros de tipo genérico estándar, no veo una excepción que se aplique en este caso (como en el caso de las interfaces).
agregado el autor SonOfPirate, fuente
Enfoque interesante. Algunas personas pueden argumentar que el prefijo T entra en conflicto con la convención que utilizas en los genéricos (por ejemplo, func (T1, T2, TResult)), pero a mí personalmente no me importa, siempre y cuando haya un consenso dentro del equipo. Los nombres son cortos, lo que hace que las cosas sean más legibles también.
agregado el autor stung, fuente