Selección de herramientas de prueba (parte 2)

En la primera entrega de esta serie presenté una arquitectura de prueba de referencia. En esta entrega voy a instanciar esa arquitectura de referencia en Ruby.

Comenzado por las pruebas del programador (unitarias y de componentes), tendremos que nuestro objeto de prueba serán clases programadas en Ruby. Para hacer este tipo de pruebas una de las herramientas más populares es RSpec la cual nos daría una arquitectura de pruebas conformada por:

  • Lenguaje de especificación: Lenguaje de Dominio Específico provisto por RSpec
  • Intérprete: es el propio RSpec
  • Driver: dado que estamos testeando clases Ruby, que estamos haciendo pruebas unitarias y de componentes y que RSpec está hecho en Ruby no requerimos de ningún driver particular. En todo caso nuestro driver es el mismo Ruby
  • Librería de aserciones: es el mismo RSpec
  • Motor de ejecución: RSpec

Un detalle a tener presente es que este tipo de pruebas son pruebas que hace el programador para sí mismo, ya sea para guiar el desarrollo (si está haciendo TDD) o bien para garantizar que sus clases se comportan acorde a lo esperado. Este tipo de pruebas no suelen interesar al usuario, pues son de índole técnica y al mismo tiempo mucho más granulares que las funcionalidades pedidas por el usuario.

arquitectura_developer_tests_ruby

 

 

Pasando ahora a las pruebas de aceptación funcionales, si bien podríamos utilizar el mismo set de herramientas, la realidad es que esperamos que el usuario esté involucrado y por ello usaremos un set distinto de herramientas de cara tener un lenguaje de especificación más “amistoso” para el usuario. Al mismo tiempo el objeto de nuestras pruebas ya no son clases sino la aplicación como un todo:

  • Lenguaje de especificación: Gherkin
  • Intérprete: Cucumber
  • Driver: dependerá de la forma en que pretendamos comunicarnos con la aplicación. Suponiendo que nos comunicamos via HTTP, podríamos utilizar Capybara en conjunto con WebDriver de Selenium.
  • Librería de aserciones: RSpec
  • Motor de ejecución: Cucumber

arquitectura_user_tests_ruby

 

Breve historia de las herramientas BDD

Uno de los mayores referentes en lo que a BDD respecta es Dan North. Hacia el año 2003 Dan se encontraba trabajando en ThoughtWorks cuando creo JBehave. Según el mismo cuenta, JBehave comenzó como un experimento para ver como podría haber sido JUnit si se hubiera concebido desde un principio como una herramienta para hacer TDD en lugar de un mero framework de pruebas automatizadas. Fue por aquel entonces que el dominio jbehave.org fue registrado. Con el correr del tiempo JBehave fue evolucionando con foco en la automatización de pruebas de aceptación.

Tiempo más tarde algunas ideas de JBehave fueron incorporadas por Dave Astels en RSpec.

Hacia 2007 Dan North inspirado por el la tracción generada por RSpec y con la intención de proveer una forma simple y elegante de describir comportamiento a nivel de aplicación publica RBehave, el cual trae como novedad la posibilidad de especificar comportamiento en texto plano, idea que luego daría origen a lo que en la actualidad se conoce como sintaxis Gherkin.

Al poco tiempo David Chelimsky incorpora en RSpec el soporte de especificaciones en texto plano.

En 2008 Liz Keogh and Mauro Taveli reescriben completamente desde cero JBehave haciendo uso de algunas característica recientemente incorporadas en Java 5 y utilizando JUnit 4 como runtime. Entre otras cosas incorporan soporte para especificaciones en texto plano e integración con Maven. El resultado es JBehave 2.

Por aquel entonces Aslak Hellesoy ya se encontraba trabajando en un reemplazo para el ejecutor de especificaciones en texto plano de RSpec, el cual sería bautizado como Cucumber. La primera versión de Cucumber fue liberada hacia fines del 2008.

Mi percepción es que Cucumber marcó un punto de inflexión en la difusión de BDD. Fue precisamente en el contexto de Cucumber que se estandarizó la sintaxis de especificación en texto plano y se la bautizó como Gherkin.

Fue tal el impacto de Cucumber, que en la actualidad existen herramientas de BDD con soporte para Gherkin implementadas en diversos lenguajes, algunas de ellas son directamente reimplementaciones de Cucumber sobre otras plataformas (tal es el caso de Cucumber-JVM).

Fuentes: