arrow_back Volver
Inicio keyboard_arrow_right Artículos keyboard_arrow_right Artículo

Pruebas automatizadas

Uriel Hernández

CTO de Código Facilito

av_timer 4 Min. de lectura

remove_red_eye 61299 visitas

calendar_today 12 Julio 2015

Una de las prácticas de desarrollo que caracteriza a un programador profesional es escribir pruebas automatizadas. Las pruebas son tan importantes que prácticamente definen el flujo de desarrollo de proyectos y equipos de trabajo grandes, hay diferentes metodologías de desarrollo de software basadas en las pruebas, una de ellas es TDD (Test Driven Development) que quiere decir, Desarrollo Basado en Pruebas.

Antes, escribí sobre lo que hace un buen desarrollador y una de las prácticas que colocaba es que escribía pruebas, como ahí mencioné TODOS los desarrolladores probamos nuestros sistemas y aplicaciones, la diferencia es cómo las probamos.

Siendo desarrollador, ¿por qué habrías de probar tu código manualmente, cuando puedes automatizar eso?. Hay infinidad de problemas en no tener pruebas automatizadas, algo bien sencillo es, imagina que actualizas un plugin / gema/ script de tu aplicación... ¿cómo sabes que todo sigue funcionando bien? Si navegas por todo el sitio y toda la app para ver que todo sigue bien... lo estás haciendo absolutamente mal. ¿Qué pasa si hay más plugins? Qué pasa si algo cambio en la base de datos, si alguien renombró una clase, si se cambió un módulo, etc. Tantas cosas cambian en un sistema que es insostenible que tengas que usar tu proyecto (probando manualmete) para encontrar errores.

Ok, bien, si no es así, ¿cómo? Automatizas tus pruebas, con esto quiero decir que escribimos código que pruebe nuestro código. Sí, así.

Aquí va un ejemplo con rspec-rails que es una gema muy popular para escribir pruebas en proyectos de Ruby on Rails

expect(response).to have_http_status(200)

El código mostrado es Ruby, Rspec es Ruby... si nunca habías visto una prueba, la única diferencia entre el código que vez arriba y el código que has escrito es que la función de este es probar otro código.

Cómo iniciar

Para mí, escribir pruebas y hacer TDD es un cambio más de mentalidad que de otra cosa, al principio escribir pruebas parece una carga más al flujo de desarrollo, parece que estás escribiendo del código (y sí escribes el doble de código) y toma un tiempo para que en realidad veas los beneficios de escribir testing, sobre todo porque al principio tienes tardas más tiempo investigando, pensando y diseñando tus pruebas a modo que puedas probar diferentes módulos de tu aplicación. Eventualmente encuentras el flujo y las herramientas para ti y tu lenguaje y todo se vuelve más fácil, empiezas a escribir código más rápido, a sacar nuevas versiones de tu aplicación más rápido, a dejar menos bugs en producción, etc. pero bueno, hay que empezar por algún lado...

Mi recomendación para iniciar es escribir pruebas unitarias, a esto le llamamos ** Unit Testing , las características de las pruebas unitarias es que pruebas componentes de software de manera aislada, algo así como probar el método de una clase de todo tu código, por decir algo. Unit testing es muy importante porque además de ser un comienzo más fácil, eventualmente notarás que **aislar un componente para probarlo no es tan fácil si no escribes código limpio; eventualmente las pruebas unitarias te ayudarán a escribir código que es independiente y por tanto es reusable. Aquí un ejemplo con Ruby que pueden ejecutar / modificar etc:

Para correr el archivo hagan click en la pestaña Terminal y ejecuten:

ruby -Ilib:test unit_test.rb 

Dentro del archivo unit_test.rb están las pruebas utilizando la gema MiniTest y una clase dummy que sólo está ahí para probar (SuperCoolClass), muevan lo que quieran, si quieren agregar más pruebas creen un nuevo método en la clase TestTester que inicie con test_ la documentación de Minitest la encuentras aquí

Tipos de pruebas

Las pruebas que vas a escribir dependen de la aplicación que estás desarrollando, así que es un tema de cada plataforma, en términos generales, además de las pruebas unitarias, tenemos las pruebas de integración... estas son más complejas y requieren de una configuración de un par de pasos más que las pruebas unitarias, la nueva plataforma de Código Facilito que estamos haciendo desde 0 tiene pruebas para casi todo, aquí les dejo una de integración con capybara que usamos para saber si el formulario de subida de vídeos funciona correctamente:

require 'rails_helper'

describe "Video creation",type: :feature do
  let!(:user) { FactoryGirl.create(:admin) }
  let!(:course) { FactoryGirl.create(:course) }

  before(:each) do
    login_as(user, :scope => :user)
  end
  it "can create a video" do
    VCR.use_cassette "" do 
      visit "/videos/new"
      fill_in "video_title", with: "Titulo video"
      attach_file "video_video_file", Rails.root + "public/videos/video.mp4"
      find("option[value='1']").click
      click_on "Guardar"
      expect(page).to have_content("Titulo video")
    end
  end
end

Particularmente en Rails con Rspec / Capybara y otros, escribes pruebas que son muy parecidas a lenguaje natural tal como lo puedes ver en el ejemplo anterior, hay muchas cosas envueltas en este test de nuestro formulario de subida.

TDD

Hasta este punto has visto cómo se ven pruebas de integración y pruebas unitarias, estas son pruebas o tests, pero entonces, ¿qué es TDD?

TDD es una metodología para escribir código en donde el desarrollo se centra en escribir tests, el ciclo de desarrollo va así:

  1. Escribo una prueba que falle (falla porque el código que hace pasar la prueba ni siquiera se ha escrito, del ejemplo anterior imagina que ni siquiera hemos creado el formulario para subir vídeos)
  2. Escribimos el código para que la prueba pase y verificamos que precisamente la prueba pase. (Del ejemplo anterior imagina que ahora sí creamos el formulario de subida de vídeo y vemos que la prueba pase)
  3. Hacemos refactor del código que escribimos y verificamos que la prueba sigue pasando.

Dónde aprendo más y Conclusión

Hay infinidad de recursos, en Código Facilito sí tenemos un curso de TDD y es precisamente el Curso de Desarrollo de APIs que además de enseñarte a crear APIs es un curso con pruebas automatizadas en Ruby on Rails, es mi parte favorita del curso :). Además el Curso de Ecommerce también incluye pruebas automatizadas.

También queremos tener cursos específicamente de pruebas en otros lenguajes, Android, javaScript, Python... ¿Qué opinan de eso?

Muchos de los frameworks que usamos están diseñados con que escribir pruebas sea más fácil, la comunidad de los distintos lenguajes promueve mucho las pruebas, es algo que definitivamente es un must have en un desarrollador avanzado. Insisto lo difícil es empezar, oblígate una semana a escribir pruebas, literalmente por fuerza, investigando, tardándote el doble en escribir pruebas que en lo que escribes código y verás que después de eso te sentirás mal si dejas de escribir pruebas, te lo aseguro.