Escribo este post para ir apuntando las cosillas que voy aprendiendo de Capybara y Steak que son dos librerías de testeos funcionales para ruby.
En mi opinión hay diferencia entre Cucumber y Steak en el hecho de que el primero ayuda a definir testeos de aceptación y el segundo funcionales. A mi entender no son lo mismo y, como programador que soy, evidentemente me estoy encontrandome más a gusto con Steak porque la idea de Cucumber es la de programar los testeos con un lenguage más cercano al utilizado por el cliente.
De todas formas conviene echarle un vistazo al ingenioso código de Steak. En nada más que 28 líneas de código, cambian el uso de las palabras example y before de RSpec por las palabras scenario y background que suenan más acorde al lenguage de aceptación de testeos además de buscar los matches de RSpec adecuados si se prefija una función con be_ o con have_. En realidad es muy poca la diferencia entre un testeo funcional con RSpec y un testeo "de aceptación" con Steak.
1 - Configurar Steak para que trabaje con Capybara
Inicialmente Steak está configurado para trabajar con Webrat, pero cambiando las siguientes lineas del fichero: spec/acceptance/acceptance_helper.rb podemos hacer que trabaje con Capybara: Quitar las siguientes lineas:
#require "webrat" #Webrat.configure do |config| # config.mode = :rails #end
Y poner estas:
require 'capybara' require 'capybara/dsl' require 'capybara/rails' require 'capybara/session' include Capybara
2 - Conocer XPath
Para buscar elementos dentro del HTML y así comprobar que tienen los valores y la estructura adecuada es conveniente utilizar XPath. Por ejemplo, si tenemos una página de empleados con un enlace a añadir un empleado nuevo (en una web de gestion de empleados de una empresa, por ejemplo), podríamos hacer un testeo como el siguiente:
page.find("//a[@id='new_empleado_link']")[:href].should == new_empresa_empleado_path(empresa)
Estamos comprobando que el enlace (href) del elemento con id: 'new_empleado_link' (que debería de ser un elemento 'a') apunta realmente a la url de crear un empleado. A mi me ayuda mucho (aunque supongo que será una práctica políticamente discutible) ponerle un id a los elementos 'a' para que sea más fácil encontrarlos dentro de la estructura de la página.
Recomiendo conocer bien el lenguage XPath, pero ayuda mucho instalar un plugin de Firefox que muestre la ruta XPath de cada elemento de la página (por ejemplo: XPather).
3 - Recorrer listas
Es relativamente sencillo testear listas de datos, pero hay que identificarlos de alguna manera dentro de la vista. Para ello recomiendo utilizar la funcion dom_id. Con ella podemos identificar unívocamente elementos pertenecientes a cada uno de los elementos de una lista. Por ejemplo, una lista de enlaces a mostrar empleados sería algo así (con Haml, por supuesto):
- @empleados.each do |empleado|
%a{:id=>dom_id(empleado, :show)}= empleado_path(empleado)
El testeo en capybara de la lista anterior, sería relativamente sencillo:
@empleados.each do |empleado|
page.find("//a[@id='#{dom_id(empleado, :show)}']")[:href].should == empleado_path(empleado)
Estos son apuntes que pueden venir bien al testear nuestras páginas con Capybara. A mi me han ayudado mucho (después de haberme dado cuenta de la poca información que hay sobre Capybara en la red). Iré incrementando mis entradas en esta blog con apuntes de testeos por si le ayuda a alguien.
Terminar diciendo que me ha sorprendido lo mucho que me está ayudando Capybara a diseñar el código HTML que genera mi aplicación. Como debe ser: Un sistema de testeo debe ayudar a diseñar la aplicación, entre muchas otras cosas.
Enviar un comentario nuevo