Twitter
RSS

JRuby + Celerity, parte 2

0
Al utilizar una API similiar a Watir, Celerity logra poder ejecutar los casos de prueba que ya hayan sido desarrollados para un ambiente en el que solo existe Ruby, Watir y el navegador.

Pero el principal problema al utilizar este tipo de herramientas es que no tenemos resultados visibles y solo podemos basarnos en que algo salio bien o no, mediante una consola.

Para solucionar esto, los casos de prueba pueden generarse para Watir, y luego ejecutarse en Celerity, pero el principal inconveniente esta en tener que reemplazar algunas sentencias que referencian a una u otra herramienta, a continuación incluyo un código en Ruby que permite olvidarnos de este problema, y centrarnos solamente en lo que es importante: la creación de los casos.


Definiendo el la configuración de los casos:

Primero debemos generar un archivo de configuración, el cual llamaremos "config.rb", en el cual indicaremos las herramientas a utilizar y así también la configuración de estas.



if RUBY_PLATFORM =~ /java/i then
  require "celerity"

  $browser = Celerity::Browser.new()

else
  require "firewatir"

  $browser = Watir::Browser.new()

end



Aunque se podría llegar a implementar de otra forma, así es posible añadirlo a nuestro script automatizado:




require "rubygems"
require "config.rb"

$browser.goto("www.google.com")

puts $browser.title.include?("Google")




Ahora podemos ejecutar nuestro script de la siguientes formas:



  • ruby test.rb
  • jruby test.rb

Ambas van a funcionar y el resultado es el mismo (en nuestro caso retorna true si el título de la página incluye "Google"), indistinto de la plataforma que se utilice, y permitiendo integrar este script a cualquier tipo de integración.

Automatización Multi Plataforma (JRuby + Celerity)

0
Uno de los grandes problemas en la automatización es la posibilidad de general casos de prueba que puedan ser multiplataforma, principalmente si hay que correr alguno de estos test en una integración continua.


Lo bueno de esto es que existen herramientas que permiten realizar estas tareas, la mayoría del tiempo me dedico a automatizar basándome en herramientas como Watir y Selenium, pero en los casos que tengo que realizar integraciones continuas prefiero desempeñarme con otras herramientas, en este caso JRuby (Reemplazando a Ruby) y Celerity (Reemplazando a Watir); la principal ventaja que existe es que ambos pueden ser diseñados de las formas tradicionales y luego ejecutados con herramientas distintas.


Gracias a que JRuby, es una implementación de Ruby en Java, permite integrarla en procesos como Maven, y además al utilizar Celerity no estamos en la necesidad de utilizar un browser, por lo que nuestros casos de prueba pueden ser ejecutados en ambientes tan variados como: Unix-like, Windows, etc, mientras la plataforma pueda ejecutar una JVM (Java Virtual Machine, Máquina Virtual de Java). 


La posibilidad de cambiar el tipo de navegador que simula Celerity, gracias a HtmlUnit, permite hacer test que puedan ser probados en los cores de Firefox o IE, aún en ambientes como por ejemplo CentOS, sin interfaz gráfica, sólo mediante una terminal.


La integración de estas herramientas permiten llevar más alla los limites de la automatización y la integración de los equipos de desarrollo y calidad. 

Unit Test en la etapa de Testing

0
En la mayoría de los proyectos actuales, cuando se desarrolla una nueva funcionalidad, antes de llegar a la etapa de testing esta pasa por los test de unidad; los desarrolladores son los encargados de realizar las tareas mínimas para probar que las funcionalidades pasen los caminos comunes, y que se comporta de manera apropiada para que sea testeado en la próxima por un equipo de QC.


Ahora, ¿se puede realizar Unit Test en la etapa de Testing?, en realidad la respuesta más común sería, NO. Pero es posible realizar casos de prueba para integrar el Unit Test, estos casos los puede desarrollar un equipo de QC, y luego se pueden integrar en un ambiente de integración continua.


Pero... ¿es esto realmente útil? ¿no genera una sobrecarga al equipo de QC? Si, y no, en el caso que el equipo de control de calidad realice actividades de automatización estas pueden integrarse muy fácilmente a la integración continua de un proyecto, además no genera sobrecarga, ya que el equipo ya se encuentra realizando tareas de automatización, por lo tanto los test de unidad en la etapa de testing son un complemento necesario para los test de unidad.


En conclusión, se pueden generar casos de prueba para integrar junto con los test de unidad, dando una mejor cobertura en las funcionalidades, además disminuyendo la cantidad de bugs en las etapas de testing.