unit testing - software - ¿Cuáles son algunas convenciones de nomenclatura populares para las pruebas unitarias?

pruebas unitarias para que sirve

Question

General

• Siga las mismas normas para todas las pruebas.
• Sea claro acerca de lo que es 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: Normas de nomenclatura para pruebas unitarias.

2) Separando cada palabra por 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

• Terminar los nombres de los métodos con Test
• Iniciar nombres de métodos con nombre de clase

Answer 1

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 algún lugar, ya sea en el nombre de la función o en el espacio de nombres o clase adjuntos.

Answer 2

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

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

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

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

En cuanto a la duración y el uso del subrayado, su código de prueba , ¿a quién diablos le importa? Solo tú y tu equipo lo verán, siempre y cuando sea legible, y claro lo que está haciendo la prueba, ¡continúa! :)

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

Answer 3

Mientras sigas una práctica, 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 suele ser de prueba (un remanente de JUnit 3).

Answer 4

Nombro mis métodos de prueba como otros métodos que usan "PascalCasing" sin guiones bajos ni separadores. Dejo fuera la Prueba postfix 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 debe probar otra clase, yo 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 "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 se puede .

[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 de TDD: Convenciones y pautas de nomenclatura de prueba" de Bryan Cook. He encontrado este artículo muy útil.

Answer 5

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.

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í es 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 juntas. Por ejemplo, si usa 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

Así que tal vez ajustarse a:

StateUnderTest_ExpectedBehavior

Porque cada prueba ya estará en una clase anidada.

Answer 6

Tiendo a usar la convención de MethodName_DoesWhat_WhenTheseConditions 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
• Acto
• Afirmar

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

• Dado
• Cuando
• Entonces

lo que sería nombrar la prueba en la forma de: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis de UnderTheseTestConditions_WhenIDoThis_ThenIGetThis de 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 entonces las pruebas se pueden ordenar alfabéticamente, o aparecen 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, a diferencia 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_WhenNegativeNumberAs1stParam mejor que Sum_Throws_Exception_When_Negative_Number_As_1st_Param .

Answer 7

Uso un prefijo ''T'' para los espacios de nombres de prueba, las clases y los 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 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 (es decir, no te confundes con las cosas que comienzan con ''I'', ni con ''T'').

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

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