É muito bom que a mentalidade de testes esteja sendo cada vez mais difundida. Com isso, desenvolvem-se as abordagens às práticas de desenvolvimento orientado por testes como, por exemplo, os frameworks. Enquanto eles se tornam cada vez mais extensíveis, eficientes e com DSLs mais limpas e bonitas, muitas pessoas esquecem que, independentemente da ferramenta, da sintaxe e da abordagem técnica a ser utilizada, a intenção do código desenvolvido é que deve ficar explícita.

Observação: ao longo desse texto, utilizarei a expressão “desenvolvimento orientado por testes”, mas você pode substituir por “desenvolvimento orientado por comportamento” ou qualquer abordagem similar.

O que é a intenção do código?

A intenção do código tem tudo a ver com algo que vem sendo muito discutido: o comportamento do software. Uma definição de comportamento é “a resposta observável de um sistema a um estímulo“. Logo, em última análise, podemos dizer que o que importa é verificar se a resposta observável de um componente de software é a esperada, dado um ou mais estímulos pré-definidos.

Em alguns casos isso significa apenas definir um estado, chamar algum método e verificar o resultado. Em outros, significa verificar também a propagação dos efeitos em outros objetos (caso onde os mocks são muito úteis). Isso vai depender do componente em desenvolvimento e da abordagem utilizada.

Como?

A pergunta é: como testes ajudam a revelar a intenção do código?

Se você escrever um monte de código confuso e, após isso, resolver escrever alguns testes para validar esse trabalho, esses testes não vão ajudar em nada. Mas, se utilizar testes para orientar seu processo de desenvolvimento, descobrirá o papel fundamental que eles terão para criar código claro, fácil de entender, utilizar e modificar. Ao especificar um cenário (o estado pré-definido onde ocorrerá o estímulo), fica muito mais simples projetar e verificar o comportamento necessário.

Geralmente, ao escrever testes antes da implementação, obtêm-se outros benefícios, tais como: uso de boa nomenclatura, simplicidade e facilidade no refactoring. Tudo isso deve-se ao fato de que, ao praticar o desenvolvimento orientado por testes, você efetivamente pensa mais sobre o que vai escrever, antes de o fazer.

Exemplo

Vou tentar exemplificar os passos de criação de um componente simples com e sem testes para orientar a implementação. Assim, ao final, teremos uma perspectiva melhor dos efeitos do processo.

Quero escrever uma aplicação para cadastrar minha coleção de filmes. Preciso de uma classe que representará o filme:

class Movie
  attr_accessor :title
end

Isso é o suficiente para o exemplo.

Agora vamos iniciar o processo de implementação da classe responsável pelo gerenciamento da coleção. Primeiro, sem teste algum.

Sei que preciso de uma classe que possua uma lista de filmes e permita que eu posso adicionar, remover, procurar e listar todos os filmes. Vamos lá:

class MovieShelf
  attr_accessor :movies
 
  def initialize
    @movies = []
  end
 
  def lookup(movie)
    @movies.detect {|m| m == movie}
  end
 
  def list
    @movies.each do |movie|
      puts movie.title
    end
  end
end

Ok, muito simples. Em dois minutos está pronto. Um exemplo de uso (no irb):

>> shelf = MovieShelf.new
=> #<MovieShelf:0x36eb88 @movies=[]>
>> m = Movie.new
=> #<Movie:0x33b328>
>> m.title = "Juno"
=> "Juno"
>> m2 = Movie.new
=> #<Movie:0x39968>
>> m2.title = "Transformers"
=> "Transformers"
>> shelf.movies << m
=> [#<Movie:0x33b328 @title="Juno">]
>> shelf.movies << m2
=> [#<Movie:0x33b328 @title="Juno">, #<Movie:0x39968 @title="Transformers">]
>> shelf.list
Juno
Transformers
=> [#<Movie:0x33b328 @title="Juno">, #<Movie:0x39968 @title="Transformers">]
>> shelf.lookup m2
=> #<Movie:0x39968 @title="Transformers">
>> shelf.movies.delete m2
=> #<Movie:0x39968 @title="Transformers">
>> shelf.list
Juno
=> [#<Movie:0x33b328 @title="Juno">]

Tudo bem, funciona e parece estar de acordo com os requisitos. Mas o código não está muito consistente. A coleção de filmes, que na prática é um objeto da classe Array, está exposta e pode ser manipulada diretamente. Isso pode ser muito ruim caso algum método da classe MovieShelf faça ações adicionais ao operar sobre a coleção. A nomenclatura também não é muito clara, entre outros pequenos problemas. Também não gostei da forma como estou criando os objetos que representam os filmes.

Agora, vamos começar com uma pequena especificação do que é preciso. Com isso, vou ter mais tempo para pensar em bons nomes e numa forma de uso limpa e direta.

context "a movie shelf" do
  setup { @shelf = MovieShelf.new }
 
  should "let the user store a movie" do
    juno = Movie.new("Juno")
    shelf.store juno
    assert shelf.contains?(juno)
  end
end

Somente estabelecendo essa primeira expectativa quanto ao comportamento do componente, já temos idéia de um início de implementação:

class Movie
  attr_accessor :title
 
  def initialize(title)
    self.title = title
  end
end
 
class MovieShelf
  def initialize
    @movies = []
  end
 
  def store(movie)
    @movies << movie
  end
 
  def contains?(movie)
    @movies.include? movie
  end
end

Continuando:

context "a movie shelf" do
  setup { @shelf = MovieShelf.new }
 
  should "show how many movies are stored" do
    juno = Movie.new("Juno")
    transformers = Movie.new("Transformers")
    shelf.store juno
    shelf.store transformers
    assert_equal 2, shelf.movies_count
  end
end

Implementando:

class MovieShelf
  def initialize
    @movies = []
  end
 
  def store(movie)
    @movies << movie
  end
 
  def contains?(movie)
    @movies.include? movie
  end
 
  def movies_count
    @movies.size
  end
end

É claro que o exemplo é bem bobo, mas perceba como a interface fica melhor e também como vamos descobrindo novas funcionalidades ao longo do processo de especificação. Este é um dos principais benefícios do desenvolvimento orientado por testes: interfaces ricas através de código modular, flexível e de intenção clara.

Não vou continuar o exemplo com as demais funcionalidades para não alongar ainda mais o artigo. Acredito que consegui expor aqui a importância da intenção do código e como deixá-la clara e fácil de entender.

O que você pensa sobre isso? Deixe sua opinião, comentário, exemplo, crítica ou sugestão.

Leia também:

• Test Driven Development: Programming by Intention
• The BDD cargo culting

Assim como nem todos são bons jogadores de futebol ou bons em matemática, nem todos serão bons ou se adaptarão ao desenvolvimento ágil de software.

Note o destaque em negrito na frase acima, pois estou aqui falando de práticas ágeis para o desenvolvimento de software, uma coisa que o Scrum não é (o Scrum é apenas um framework gerencial “ágil”, podendo ser aplicado à projetos de software ou de outros mercados). Extreme Programming já vai além, sendo, essa sim, uma metodologia de desenvolvimento ágil de software (que, por usa vez, usa muitos conceitos gerenciais do Scrum no que diz respeito à comunicação intra e extra-equipe).

Cada metodologia possui um conjunto de princípios básicos, algumas possuem práticas e, outras, formatos bem específicos de documentos a serem seguidos fielmente. Algumas possuem tudo isso junto.

De acordo com o perfil psicológico, social e profissional, é comum que pessoas envolvidas em desenvolvimento de software (gerentes, desenvolvedores, designers, testadores etc) possuam suas preferências quanto à metodologias e práticas. Alguns se dão muito bem apenas com waterfall, outros apenas com agile, uns poucos com ambas e muitas outras. E isso é extremamente normal. As metodologias ágeis são vistas como a salvação do mundo do desenvolvimento de software, principalmente num mercado dinâmico como a internet. Mas, não se engane, nem todos os profissionais conseguem trabalhar num ambiente realmente ágil. Eles são piores do que os que conseguem? Não. São apenas pessoas diferentes.

Ambientes “ágeis” exigem um conjunto de habilidades bem diferentes em relação a outros tipos de ambientes. Geralmente, exigem também muito sacrifício pessoal em detrimento do próprio ego, sendo essa uma das principais barreiras para que se consiga implementar uma cultura de desenvolvimento ágil de software.

Alguns profissionais (desenvolvedores e outros) não estão acostumados e não querem praticar coisas como feedback rápido, desenvolvimento orientado por testes, daily meetings e as outras práticas que as acompanham. Desenvolvimento ágil de software não é apenas escrever centenas de post-its e colá-los num quadro branco ou numa parede. É estar disposto a mudar muitos hábitos e fazer alguns sacrifícios, aceitar algumas “imposições” das metodologias, trabalhar em equipe e para a equipe.

Se a pessoa não se encaixa nesse tipo de mentalidade, tudo bem. Não significa nada em termos de qualidade profissional, mas uma empresa que deseja trabalhar com métodos ágeis definitivamente não é o lugar certo para ela, já que ambos os lados sairão perdendo.

Em linhas gerais, integração contínua é a prática de constantemente enviar as alterações feitas no código fonte ao sistema de controle de versão para que os demais desenvolvedores sempre trabalhem com a versão mais atualizada do código. Recomenda-se também que esse processo inclua testes unitários, garantindo que todo código integrado ao servidor está correto e não “quebra” outra parte da aplicação.

Leia mais aqui e aqui.

Recentemente foram escritos dois posts muito bons sobre o assunto. Você pode conferí-los no blog da ImproveIT e do Urubatan.

Nesses posts também é possível aprender sobre integração contínua síncrona e integração contínua assíncrona. Obrigado ao Vinícius e ao Urubatan pelas ótimas referências.