[2] Aunque estas herramientas son comúnmente desarrolladas específicamente para su uso en proyectos de DGC, se pueden ver como formas especializadas de las herramientas que asisten en el DGP.Los criterios de validación deberían estar escritos en términos de las situaciones y además implementados como cláusulas: (usando el principio Given-When-Then) Dado que [contexto inicial], cuando [ocurre el evento], entonces [asegurar algunos resultados].[5][6] Durante el congreso "Especificaciones ágiles, DGC y Pruebas" ("Agile specifications, BDD and Testing eXchange") en noviembre de 2009 en Londres, Dan North[7] dio la siguiente descripción del DGC:Dan North creó el primer armazón del DGC, JBehave,[1] seguido por un armazón nivel de historia DGC para Ruby llamado RBehave,[8] el cual fue integrado más tarde al proyecto RSpec.El primer armazón basado en historia dentro de RSpec fue reemplazado poco tiempo después por Cucumber, principalmente desarrollado por Aslak Hellesøy.[2][4][10] Tomando prestado del desarrollo ágil de software, el concepto de "comportamiento deseado" en este caso consiste en los requerimientos definidos por el negocio -- esto es, el comportamiento deseado que tiene valor rentable para cualquier entidad que haya comisionado la unidad de software que se encuentra en construcción.[2][11] Sin embargo, en 2007 Dan North sugirió una plantilla para un formato textual, la cual ha encontrado amplio seguimiento en diferentes herramientas DGC de software.[12] Este formato es conocido como el lenguaje Gherkin, que tiene una sintaxis similar al ejemplo de arriba.El término Gherkin, sin embargo, es único para las herramientas de software Cucumber, JBehave y Behat.[18] Este modelo es también base para las diferentes herramientas de software disponibles que usan DGC.Cada una de estas partes está definida exactamente por la parte más formal del lenguaje (el término Dado que puede considerarse como una palabra clave, por ejemplo) y por tal causa es posible que sea procesada de alguna manera por una herramienta que entienda las partes formales del lenguaje ubicuo.Sin embargo, donde las herramientas DGP tienden a ser libres de formato referente a lo que se permite para pruebas de especificación, las herramientas DGC están relacionadas con la definición del lenguaje ubicuo discutida anteriormente.La implementación exacta de esto varía por cada herramienta, pero la práctica ágil ha presentado el proceso general siguiente: Dan North ha desarrollado un número de armazones que apoyan el uso del DGC (incluyendo JBehave y RBehave), cuya operación se basa en la plantilla que él sugirió para recopilar historias de usuarios.JBehave después toma estas cláusulas y las pasa a código que es capaz de preparar una prueba, respondiendo a los detonadores de eventos y verificando el resultado.Este código debe estar escrito por los desarrolladores en el equipo del proyecto (en Java, porque esa es la plataforma en que se basa JBehave).En este caso: La función primaria de este código es el ser un puente entre un archivo de texto con una historia y el código en sí que se está probando.Un ejemplo de este estilo es la herramienta RSpec, que también fue desarrollada por Dan North.[2][20] Un ejemplo de una especificación para una pila podría verse así: Tal especificación puede especificar exactamente el comportamiento que se está probando, pero tiene mayor insignificancia para un usuario de negocios (inversionistas por ejemplo).
