Página Inicial > Eventos, Ruby, TDD > fisl10 - TDD e Rails: Mais rápido, mais forte e melhor

fisl10 - TDD e Rails: Mais rápido, mais forte e melhor

A primeira apresentação que assisti no fisl10 foi muito boa. Lucas Húngaro mostrou formas de criar aplicações Ruby on Rails com testes, passando um pouco da sua experiência em desenvolvimento Web.

Lucas Húngaro

A palestra foi dividida em quatro partes: Fundamentos, Abordagens, Como eu desenvolvo com testes no Rails e Dicas. Mas separei aqui em mais duas: Boas Práticas e Maus Sinais.

Fundamentos

  • TDD, BDD e suas suas diferenças.


Abordagens

  • Outside-in: perspectiva dos usuários, testes de fora para dentro. São os testes de aceitação, mostram onde chegar.
  • Inside-out: perspectiva do desenvolvedor, testes de dentro para fora. São os testes unitários, mostram como chegar.
  • Atenção para não duplicar testes. Por exemplo, quando testar validações no model, não testar novamente essa validação no teste do controller que usa esse model.


Como eu desenvolvo com testes no Rails

  • Testes unitários somente para models, testes funcionais mínimos e testes de aceitação guiando seu design de alto nível.
  • Não fazer testes para helpers: se há uma complexidade em um helper que precise de um teste, essa lógica não deveria estar na View. Os helpers devem contém formatação e não lógica de negócio.
  • Processo ideal: criar uma feature no Cucumber e vai descendo do alto nível (browser, session/routes, view) para os níveis mais baixos (controllers, models).


Dicas

  • Use factories para fazer testes.
  • Especifique os casos de falha, não crie testes somente para a execução perfeita da funcionalidade.
  • Os testes precisam revelar o comportamento e a intenção. Testes com nomes de métodos ficam esquisitos, coloque no nome do teste o comportamento que você está testando.
  • Testes não precisam ser totalmente DRY (Don’t Repeat Yourself), pois devem ser muito fáceis de entender, somente “batendo o olho”.
  • Use com moderação objetos de substituição (mocks, stubs, proxies, etc).
  • Não utilize mocks como stubs.
  • Não confie cegamente em métricas: é muito fácil criar testes que não testam nada e que aumenta a cobertura de testes.


Boas práticas

  • Não substitua (com mocks, por exemplo) o objeto que você está testando.
  • Crie wrappers para objetos que você não é dono, ao invés de tentar modificar os objetos de terceiros nos seus testes, já que no Ruby você tem o poder para alterar tudo.
  • Teste também o que não deve acontecer, sendo explícito a respeito disso.


Maus sinais

  • Métodos de setup longos: você está testando muita coisa ao mesmo tempo e seu design provalmente está acoplado.
  • Falta de testes de integração: você irá perder a sincronia com as alterações que são feitas nos testes unitários.

.
Grande parte do que foi passado na apresentação se aplica em qualquer plataforma onde você esteja desenvolvendo orientado a testes.

O arquivo PDF com slides da apresentação você pode baixar aqui. O que achei muito legal desses slides é que eles vêm comentados com o texto de base para a apresentação, ou seja, praticamente você pode “ler” a apresentação que foi feita.
.
Post original:
http://tecblog.locaweb.com.br/2009/06/30/fisl10-tdd-e-rails-mais-rapido-mais-forte-e-melhor


Eventos, Ruby, TDD , , , , , , , , , , , , ,

  1. 30, junho, 2009 em 17:37 | #1

    Obrigado pelos elogios, Fernando! Gostei do seu resumo. :)

    Ah, nessa foto aí dava pra ver minha “cara de zumbi” né, quase não tinha dormido aquele dia e foram momentos tensos antes da palestra, devido à sala ser meio escondida e eu ter que ficar “preso” naquele canto pela falta de um cabo VGA maior. Mas, ao final, tudo correu bem.

  1. Nenhum trackback ainda.