Share
La idea central de Test-Driven Development (TDD) es escribir pruebas antes de escribir cualquier código funcional, y luego escribir solo la menor cantidad posible de código necesaria para hacer que se pasen las pruebas. Puede parecer extraño que se desarrolle de esta manera, pero en realidad es bastante útil, ya que la base de prueba se duplica como una especificación parcial del código principal.
Sin embargo, dada una premisa tan simple, hay una cantidad asombrosa de terminología y técnicas. En este artículo, reúno los términos y palabras de moda más importantes que puede escuchar y los defino..
La primera programación de prueba permite pruebas funcionales de alto nivel.
El nivel más alto de prueba valida que el software cumpla con los requisitos del cliente. Las pruebas de aceptación se ejecutan comúnmente en entornos lo más cerca posible de la producción. Ver pruebas funcionales y pruebas del sistema..
Las aserciones son declaraciones que realizan una comprobación real de la salida del software. En general, una sola función llamada afirmar es suficiente para expresar cualquier cheque. En la práctica, las bibliotecas de prueba a menudo tienen muchas funciones de afirmación para satisfacer necesidades específicas (como assertFalse, afirmar y más) para ofrecer un mejor análisis y una salida más amigable.
Una técnica de prueba que incorpora pruebas se duplica al software, afirmando que llama a los métodos correctos en un orden correcto. Ver simulacro para un ejemplo. También vea las pruebas estatales.
Un subconjunto de TDD impulsado por la necesidad de una comunicación más clara y la documentación adecuada. BDD es quizás el mayor desarrollo reciente en TDD.
Su idea central es reemplazar la terminología confusa y centrada en el desarrollador (pruebas, suites, afirmaciones etc) con lenguaje ubicuo que todas las partes interesadas participantes (incluido el personal no técnico y, posiblemente, los clientes) pueden comprender.
Ver historia de usuario.
Un principio general en las pruebas en las que la persona que escribe las pruebas no conoce o evita los aspectos internos del software, y elige en su lugar probar la interfaz pública del software estrictamente por su interfaz o especificación. Ver pruebas de caja blanca..
Una estrategia para escribir pruebas para detectar errores uno por uno y otros tipos de errores similares. Para realizar pruebas de valor de límite, pruebe las entradas alrededor de ciertos límites posiblemente problemáticos. En caso de enteros, esto podría ser 0, -1, MIN_INT, MAX_INT y otros valores similares.
Las aserciones son declaraciones que realizan una comprobación real de la salida del software.
Un dummy es un tipo de prueba doble que nunca es usado por el software real, pero solo se usa en pruebas para llenar los parámetros requeridos.
Las falsificaciones son duplicaciones de prueba que implementan la funcionalidad requerida de una manera que es útil en la prueba, pero que también lo descalifica efectivamente para ser utilizado en el entorno de producción. Por ejemplo, una base de datos clave-valor que almacena todos los valores en la memoria y los pierde después de cada ejecución, potencialmente permite que las pruebas se ejecuten más rápido, pero su tendencia a destruir datos no permitiría su uso en la producción.
Un entorno particular que debe configurarse antes de que se pueda ejecutar una prueba. Por lo general, consiste en configurar todos los dobles de prueba y otras dependencias para el software bajo prueba: como insertar datos predefinidos en una base de datos falsa, configurar cierta estructura de directorios en el sistema de archivos falso, configurar propiedades en las dependencias del software bajo prueba.
Una actividad de prueba de alto nivel que verifica que se cumplan todos los requisitos comerciales del producto. Las pruebas funcionales comúnmente involucran el uso de historias de usuario para enfocarse en un nivel más alto de requisitos para cubrir tantos escenarios de uso como sea posible. Ver pruebas de aceptación y pruebas del sistema. Por ejemplo:
# En este ejemplo, verificamos que la página de la página web funciona como se espera. Abra 'example.com' haga clic en 'acerca de nosotros' assertThereIs 'Somos una pequeña empresa de ejemplo'
Un coloquialismo para una colección de pruebas aprobadas o, a veces, una prueba pasajera en particular. Ver rojo.
Una actividad de prueba de nivel medio que verifica un cierto conjunto de módulos funciona correctamente juntos. Las pruebas de integración son como pruebas unitarias sin utilizar pruebas dobles para un cierto subconjunto de dependencias, esencialmente probando las interacciones entre el software y sus dependencias. Ejemplo:
Accentsconagua
# En este ejemplo, verificamos que el usuario recién registrado, # que fue referido por otro usuario, se crea una "amistad" en el sitio. # Aquí verificamos la interacción entre el controlador de formulario, # la base de datos y un registro activo de usuario db = new Fake Db u1 = db.createUser (name = 'john') RegistrationForm (db, name = "kate", referido = "john ") .save () assert (u1.hasFriend ('kate')) Un tipo de prueba doble creado para una prueba particular o un caso de prueba. Espera ser llamado un número específico de veces y da una respuesta predefinida. Al final de la prueba, un simulacro genera un error si no fue llamado tantas veces como se esperaba. Un simulacro con expectativas estrictas es parte del marco de afirmación. Ejemplo:
# En este ejemplo, usamos una base de datos simulada para verificar que el formulario # usa la base de datos para almacenar el nuevo usuario. # Si no se ha llamado a la base de datos al final de la prueba, # el simulacro mismo generará un error de aserción. db = nuevo Mock Db db.expect ('save'). once (). con (name = 'john') RegistrationForm (db, name = "john"). save () Una forma de extender y cambiar el comportamiento de objetos y clases existentes en un lenguaje de programación. El parcheo de monos se puede usar como una alternativa a la inyección de dependencia y la prueba de dobles modificando directamente las funciones existentes que son invocadas por el software bajo prueba (y cambiándolas después de la prueba).
# En este ejemplo, reemplazamos la función de biblioteca estándar # para evitar que la prueba use un sistema de archivos real systemystem.listdir = f (nombre) -> ['.', '...', 'foo', 'bar']; assertEqual (MyFileSearch ('foo'). count (), 1) Un coloquialismo para una colección fallida de pruebas o, a veces, una prueba fallida en particular. Ver verde.
El proceso de mejorar los detalles de implementación de código sin cambiar su funcionalidad..
La refactorización sin pruebas es un proceso muy frágil, ya que el desarrollador que realiza la refactorización nunca puede estar seguro de que sus mejoras no están rompiendo algunas partes de la funcionalidad.
Si el código se escribió usando un desarrollo guiado por pruebas, el desarrollador puede estar seguro de que su refactorización tuvo éxito tan pronto como todas las pruebas pasen, ya que toda la funcionalidad requerida del código sigue siendo correcta.
Un defecto de software que aparece en una característica particular después de algún evento (generalmente un cambio en el código).
Prueba de escenarios
Ver pruebas funcionales.
Un proceso de preparación de un accesorio. Ver desmontaje. Ejemplo:
# En este ejemplo, preparamos una base de datos falsa con algunos valores falsos # que necesitaremos en múltiples pruebas db = new Db falso db.createUser (name = 'john') db.createUser (name = 'kate') db.createFriendship 'john', 'kate')
Una forma de prueba unitaria cuando el código de prueba proporciona pruebas de duplicación y afirma que el estado de estas duplicaciones se ha modificado de manera correcta. Ver pruebas de comportamiento.
# En este ejemplo, como en un ejemplo sobre objetos simulados, # verificaremos que el formulario use la base de datos para almacenar el nuevo usuario. # Esta vez verificaremos el estado, en lugar del comportamiento db = new Fake Db RegistrationForm (db, name = "john"). Save () assertInList ('john', db.listUsers ()) Los falsos son dobles de prueba que nunca son utilizados por el software real.
Un tipo de prueba doble que puede responder al software que se está probando con respuestas predefinidas. Sin embargo, a diferencia de los simulacros, los apéndices no suelen verificar si se han llamado correctamente, sino que solo se aseguran de que el software pueda llamar a sus dependencias..
Una actividad de prueba de alto nivel cuando la totalidad del software se prueba de arriba a abajo. Esto incluye pruebas funcionales, así como la verificación de otras características (como el rendimiento y la estabilidad).
Una abreviatura de software bajo prueba. Se utiliza para distinguir el software bajo prueba de sus dependencias..
Un proceso de limpieza de un accesorio. En los lenguajes recolectados en la basura, esta funcionalidad se maneja de forma automática. Ver configuración.
La comprobación más pequeña posible para la corrección. Por ejemplo, una sola prueba para un formulario web podría ser una comprobación de que, cuando se le proporciona una dirección de correo electrónico no válida, el formulario advierte al usuario y sugiere una solución. Ver caso de prueba.
Una colección de pruebas agrupadas por un atributo. Por ejemplo, un caso de prueba para un formulario web podría ser una colección de pruebas que verifique el comportamiento del formulario para diferentes entradas válidas e inválidas.
función t1: assertNoError (RegistrationForm (nombre = 'john', contraseña = "batería correcta]]. save ()) función t2: assertError (MissingPassword, RegistrationForm (nombre = 'john'). save ()) función t3: assertError (StupidPassword, RegistrationForm (nombre = 'john', contraseña = "contraseña"). guardar ())
Las historias de usuario generalmente se definen en idiomas humanos para enfocarse en la experiencia del usuario..
Cualquier tipo de métrica que intente estimar la probabilidad de un comportamiento importante del SUT todavía no está cubierta por las pruebas. Las técnicas más populares incluyen diferentes tipos de cobertura de código: técnicas que aseguran que todas las declaraciones de código posibles (o funciones, o ramas lógicas en el código) se hayan ejecutado durante la prueba.
Un proceso de desarrollo TDD. Dado que el desarrollo de TDD comienza con la escritura de algunas pruebas, está claro que la serie de pruebas comienza en rojo. Tan pronto como el desarrollador implementa todas las funcionalidades recientemente probadas, las pruebas se vuelven verdes. Ahora el desarrollador puede refactorizar con seguridad su implementación sin el riesgo de introducir nuevos errores, ya que tiene un conjunto de pruebas en el que confiar. Una vez que se completa la refactorización, el desarrollador puede comenzar el ciclo nuevamente escribiendo más pruebas para obtener más funcionalidad nueva. Por lo tanto, la ciclo de prueba rojo-verde-refactor.
Prueba de doble
Los dobles de prueba son objetos que el código de prueba crea y pasa al SUT para reemplazar las dependencias reales. Por ejemplo, las pruebas unitarias deben ser muy rápidas y solo probar una pieza particular de software.
Por estas razones, sus dependencias, como las bases de datos o las bibliotecas de interacción del sistema de archivos, generalmente se reemplazan por objetos que actúan en la memoria en lugar de hablar con una base de datos o sistema de archivos real.
Hay cuatro categorías principales de dobles de prueba: falsos, falsos, talones y simulacros.
Una colección de casos de prueba que prueban una gran parte del software. Alternativamente, todos los casos de prueba para un software en particular.
La prueba de caja blanca permite un análisis más profundo de posibles problemas en el código.
La programación de prueba en primer lugar es un término ligeramente más amplio para el desarrollo basado en pruebas. Mientras que TDD promueve el acoplamiento estrecho entre las pruebas de escritura (generalmente pruebas unitarias) y la escritura del código, la programación de la primera prueba permite realizar pruebas funcionales de alto nivel. Sin embargo, la distinción en el uso general rara vez se nota, y dos de los términos se usan indistintamente.
La técnica de prueba de nivel más bajo consiste en casos de prueba para las unidades de código más pequeñas posibles. Una prueba de una sola unidad por lo general verifica solo un pequeño comportamiento particular, y un caso de prueba de una unidad generalmente cubre toda la funcionalidad de una función o clase en particular.
Una sola descripción de un grupo particular de personas dispuestas a realizar una tarea particular utilizando el SUT para lograr un objetivo particular. Las historias de usuario generalmente se definen en lenguajes humanos, usando términos simples y centrados en el usuario para evitar considerar los detalles de la implementación y centrarse en la experiencia del usuario. Por ejemplo:
Como usuario, quiero poder encontrar a mis amigos en este sitio web por mi libreta de direcciones, en lugar de buscarlos uno por uno, porque eso me ahorrará mucho tiempo..
La prueba de caja blanca es una técnica de prueba cuando una persona que realiza la prueba conoce o puede leer los aspectos internos del SUT. A diferencia de las pruebas de caja negra más comunes, las pruebas de caja blanca permiten un análisis más profundo de posibles problemas en el código.
Por ejemplo, un valor de límite particular puede no parecer uno basado únicamente en la especificación del software, pero puede ser obvio a partir de su implementación.
Además, cualquier técnica de cobertura de prueba suele ser, por definición, una parte de la prueba de caja blanca.
