The Turning Point » Tests http://blog.franktrindade.com Agile, software and some nonsense Tue, 31 Jan 2012 21:30:58 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Page Model with Cucumber and Capybara http://blog.franktrindade.com/2011/03/04/page-model-with-cucumber-and-capybara/ http://blog.franktrindade.com/2011/03/04/page-model-with-cucumber-and-capybara/#comments Fri, 04 Mar 2011 20:59:31 +0000 franktrindade http://blog.franktrindade.com/?p=516 I’ve spent some time today changing the Cucumber/Capybara tests in one of my pet projects to use a page model. Since I didn’t find much stuff on the interwebs about it, why not write it here ?

The idea behind having a page model is to keep steps related to a specific page on your app in the same place, so you can reduce the repetition of steps in different tests. Is definitely not a complicated practice, and setting Capybara for it is a simple step.

Setting the context, Im using Cucumber 0.10 with Capybara 0.4.1.2 and Rails 3.0.1. Have done the standard installation steps recommended by the cucumber-rails github page.

The only modification I’ve made with the created structure is adding a folder for the page objects, so the final structure is this:

As you can see, inside the pages folder there is a home page file, which is responsible for every action/assertion related to the home page.

Nothing new with the cucumber features, which keep having it’s standard style

Feature: Manage tasks
In order to manage my tasks,
a user
wants to create tasks in different categories

Scenario: Create a new task
Given I am in the Do Me home page
When I create an urgent and important task with description "my task"
Then I should see "my task" in the "Urgent and Important" section

However, in order to create our page object, we need to inject the test driver on it, which in Capybara’s case, is the session object.

Given /^I am in the home page$/ do
@home_page = HomePage.new(Capybara.current_session)
@home_page.visit
end

When /^I create an urgent and important task with description "([^"]*)"$/ do |task_description|
@home_page.fill_task_description(task_description)
@home_page.check_important
@home_page.check_urgent
@home_page.create_task
end

And from there is just the trouble of creating the page class (or do like me, who shamelessly copied the style from here).


class HomePage


URL = "/"

def initialize(session)
@session = session
end

def visit
@session.visit URL
end

def fill_task_description(description)
@session.fill_in("Description", :with => description)
end

def check_urgent
check("Urgent")
end

def check_important
check("Important")
end

def create_task
@session.click_button("Create Task")
end

And that’s pretty much it, now is just choosing your preferred driver and run the tests. As you can see, not much effort for a nice improvement.

]]> http://blog.franktrindade.com/2011/03/04/page-model-with-cucumber-and-capybara/feed/ 3 Behaviour Driven Development http://blog.franktrindade.com/2008/02/20/behaviour-driven-development/ http://blog.franktrindade.com/2008/02/20/behaviour-driven-development/#comments Wed, 20 Feb 2008 15:22:40 +0000 franktrindade http://franktrindade.wordpress.com/?p=23 Para os que não sabem, atualmente eu estou em Bangalore, na Índia, participando do treinamento que a Thoughtworks oferece aos seus novos graduates, a ThoughtWorks University.

Bom, ontem, depois de assistir a uma sessão opcional do curso, apresentada pela Liz Keogh, eu finalmente posso dizer que entendo o que é Behaviour Driven Development, o famoso BDD. Essa é uma das buzzwords do mundo do software que circula ha algum tempo, mas devo confessar que nunca consegui parar para verificar o que era, e sempre imaginei que fosse mais uma metodologia ágil, tipo o FDD.

Acontece que o Behaviour Driven Development é algo talvez até mais simples, mas nao por isso menos interessante :-) .

BDD nada mais é do que uma “otimização” do desenvolvimento orientado a testes, que tem como sua principal característica, e ainda mais importante, benefício, o fato de codificar as aplicações em uma linguagem voltada para o que é mais importante e muitas vezes esquecido, o resultado que a aplicação tem para o cliente.

Olhando por aí, uma justificativa interessante que eu achei foi a seguinte, no blog do Dan North:

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

Já que todos (todos?) concordamos que entregar valor de negócio para o que cliente é o que realmente importa no desenvolvimento de uma aplicação, porque não desenvolver essa aplicação de acordo com a linguagem do cliente, de forma que até ele possa entender (mesmo que em um nível básico) o que a aplicação está fazendo, e para que serve aquele código.

É claro que não é só esse o benefício, já que muitos de vcs devem estar pensando: para que diabos o meu cliente que ver o código-fonte do software?

Mas desenvolver código-fonte de acordo com a linguagem do negócio também auxilia o desenvolvedor a entender e discutir as funcionalidades que ele está desenvolvendo, e realmente saber qual é o objetivo de ele sentar na frente do computador 8 horas por dia, o que invariavelmente resulta em código de melhor qualidade.

Comentários?

Um abraço.

]]> http://blog.franktrindade.com/2008/02/20/behaviour-driven-development/feed/ 0