![[HTML5 Desarrollado usando CSS3]](http://www.w3.org/html/logo/badge/html5-badge-h-css3.png "[HTML5 Desarrollado con CSS3 / usando CSS3 ] CSS3: se utilizan las últimas caracterísiticas de estilo mejorando el diseño de las aplicaciones. También se incluyen tecnologías como Web Open Font Format (WOFF) para controlar las tipografías utilizadas en la web."){kind=icon}
En este artículo se dan unas pequeñas normas sobre la forma de nombrar las funciones de prueba de los test unitarios usando la técnica de desarrollo BDD (Behaviour Driven Development),
Hay dos técnicas de desarrollo ágil que son las más usadas y más extendidas en la actualidad: TDD (Test Driven Development) y BDD (Behaviour Driven Development), las cuales tienen un fin común, mejorar la calidad del software producido.
Desarrollo guiado por pruebas o TDD (Test Driven Development) es una técnica de programación que se centra en el hecho de que las pruebas las escribes antes de programar la funcionalidad, siguiendo el ciclo {falla, pasa, refactoriza} (red, green, refactor) intentando así mejorar la calidad del software que producimos.
Pero como todo también tiene sus fallos, ya sea por no entender bien la filosofía, o por querer llevarla a un extremo, algunos de los problemas que tiene TDD son:
Para intentar solucionar algunos de estos problemas nace BDD y se usan otras técnicas como los Test de Aceptación.
El Desarrollo Guiado por el Comportamiento o BDD (Behaviour Driven Development), es un proceso que amplía las ideas de TDD y las combina con otras ideas de diseño de software y análisis de negocio para proporcionar un proceso (y una serie de herramientas) a los desarrolladores, con la intención de mejorar el desarrollo del software, BDD se basa en TDD formalizando las mejores prácticas de TDD, clarificando cuales son y haciendo énfasis en ellas.
En BDD no probamos solo unidades o clases, probamos escenarios y el comportamiento de las clases a la hora de cumplir dichos escenarios, los cuales pueden estar compuestos de varias clases,
Algunos de los hábitos que fomenta BDD, añadiéndose a los que aporta TDD son:
A la hora de llevar a la práctica BDD es muy recomendable usar un [DSL]que nos ofrece un lenguaje común sobre el que poder hacer los test y así disminuir la fricción a la hora de compartir los test.
Los DSL más usados a la hora de definir escenarios en BDD suelen constar de [Steps] o pasos, se suelen dividir en:
Usar un DSL en vez de un lenguaje natural a la hora de especificar nos puede ayudar a mantener el mismo nivel de abstracción a la hora de definir los escenarios, un buen DSL es flexible y potente una vez todos los miembros de una organización lo conocen y usan.
Todo esto nos sirve para comprobar el comportamiento interno de la aplicación, una vez esté la funcionalidad hecha, queremos saber si es lo que buscaba realmente el usuario, para ello existen los test de aceptación.
Vamos a describir una Convención de nomenclatura estándar y legible que es la que usan esos programas DSL. Para dar nombres a los métodos de prueba
''' <summary> Operación de sumar dos números </summary> ''' <param name=paramPrimerSumando"> [Double] El primer sumando</param>" ''' <param name=paramSegundoSumando">[Double] El segundo sumando</param>" ''' <returns>La suma de los dos números recibidos por parámetro</returns> Public Function Sumar(ByVal paramPrimerSumando As Double, ByVal paramSegundoSumando As Double) As Double Return (paramPrimerSumando + paramSegundoSumando) End Function
Vamos a describir los escenarios de prueba de la función Sumar
Verificar el método "Sumar"
Ahora según el principio tradicional, vamos a escribir el método de prueba para "Sumar"
<TestMethod()>
Public Sub Test_SumarMethod()
'----------------------
' Arrange
'----------------------
Dim OB As New OperacionesBasicas
Dim primerValor As Double = 10D
Dim segundovalor As Double = 15D
Dim valorCalculado As Double = 0D
Dim valorEsperado As Double = 25D
'----------------------
'Act
'----------------------
valorCalculado = OB.Sumar(primerValor, segundovalor)
'----------------------
''Assert
'----------------------
Assert.AreEqual(valorEsperado, valorCalculado)
End Sub
Hasta aquí, hemos cubierto el caso positivo de la prueba con " CP1". Pero ¿Qué nombre asignamos al resto de los casos? Vanos a estudiar la convención de nombres BDD
El nombre de la función {Test Unitario} estará compuesto por una frase que tiene tres partes diferenciadas
El nombre de la función {Test Unitario} quedará algo asi : Given_{texto con los valores de prueba} _When{método que se ejecuta}_Then {Resultado esperado]
Un Ejemplo:
Nombre del Método – Según la convención de nombres BDD:
El método de prueba quedará más o menos así:
<TestMethod()> Public Sub Given_Parametros_Con_Valores_Positivos_When_Sumar_Se_Llama_Then_Debe_Devolver_Valor_De_la_Suma() '---------------------------------------- 'Casos de prueba – CP1 'CP1: Si los dos valores (de los parámetros) son positivos, ' debe devolver el resultado esperado 'Datos de la prueba: PrimerSumando = 10, SegundoSumando = 15 'Nombre del Método – Según la convención de nombres BDD '---------------------------------------- '---------------------- ' Arrange '---------------------- Dim OB As New OperacionesBasicas Dim primerValor As Double = 10D Dim segundovalor As Double = 15D Dim valorCalculado As Double = 0D Dim valorEsperado As Double = 25D '---------------------- 'Act '---------------------- valorCalculado = OB.Sumar(primerValor, segundovalor) '---------------------- 'Assert '---------------------- Assert.AreEqual(valorEsperado, valorCalculado) End Sub
Nombre del Método – Según la convección de nombres BDD:
En resumen, el segundo método de prueba que corresponde al caso de prueba dos [CP2], se llamara:
El método de prueba quedará mas o menos asi:
<TestMethod()> <ExpectedException(GetType(System.ComponentModel.InvalidEnumArgumentException), "CP2 Si los dos valores (de los parámetros) son cero (0), " & _ "debe disparar el error InvalidArgumentException")> Public Sub Given_Parametros_Con_Valores_Cero_When_Sumar_Se_Llama_Then_Debe_Devolver_Error_InvalidArgumentException() '---------------------- ' CP2 Si los dos valores (de los parámetros) son cero (0), ' debe disparar el error InvalidArgumentException ' Datos prueba: PrimerSumando = 0, SegundoSumando = 0 '---------------------- ' Arrange '---------------------- Dim OB As New OperacionesBasicas Dim primerValor As Double = 0D Dim segundovalor As Double = 0D Dim valorCalculado As Double = 0D Dim valorEsperado As Double = 0D '---------------------- 'Act '---------------------- valorCalculado = OB.Sumar(primerValor, segundovalor) '---------------------- 'Assert '---------------------- ' No se usa porque tiene que dispararse la excepción End Sub
En resumen, el tercer método de prueba que corresponde al caso de prueba tres [CP3], se llamara:
En resumen, el cuarto método de prueba que corresponde al caso de prueba cuatro [CP4], se llamara:
Generalmente se sigue la estructura AAA porque es fácil de leer y entender.
| © 1997 - - La Güeb de Joaquín | |||||
|
Joaquín Medina Serrano
|
|||||
|
| Codificación | |
| Fecha de creación | |
| Última actualización | |
|
|