SOLID através de     BDD um guia prático para rubistas         Lucas Húngaro         software developer
SOLIDConjunto de princípios desenvolvidos por Bob Martin que devem ser aplicados para melhorara qualidade do código orient...
Rails, MVCRails, MVC e facilitam muito a vida do desenvolvedor, principalmente em aplicações simples.Mas também deixamos d...
Fat Models                          aka                     programação                      proceduralAssim acabamos dese...
OOP, BDD, SOLIDAs soluções são simples mas, muitas vezes, acabam ficando de lado porque a maioria dosdesenvolvedores pensam...
Acadêmico...                        (chato)Um dos motivos para isso é a origem acadêmica, onde muitas vezes o assunto é di...
Coisa de Javeiro...Outro problema é que muitos associam essas práticas à plataformas como Java e .NET que,infelizmente, re...
Linguagem                           dinâmicaMas, para nossa sorte, utilizar esses princípios em linguagens dinâmicas é mui...
SRP e DIPPra facilitar as coisas, vamos falar apenas de dois princípios: Single Responsibility eDependency Inversion - os ...
Coesão e                     Acoplamento“Traduzindo” esses princípios, identificamos que eles falam sobre duas característi...
Baixa coesão:      executa parte de uma       responsabilidade ou           mais de umaProblemas que queremos eliminar
Alto acoplamento:  código preso a um caso       de uso e suas      dependênciasProblemas que queremos eliminar
Code!Exemplos
Processo usual:
rails new myapp
migrations
finders
data-centric apps                         fat modelsComeçamos pelos dados (schema) e depois tentamos derivar algum comport...
Rails apps                 ==         model User gigante           mais algumas            classes sem           importânc...
class User < ActiveRecord::Base       attr_accessible :email, :password,                       :password_confirmation     ...
class User < ActiveRecord::Base      attr_accessible :email, :password,                      :password_confirmation      h...
class User < ActiveRecord::Base      attr_accessible :email, :password,                      :password_confirmation      h...
class User < ActiveRecord::Base      attr_accessible :email, :password,                      :password_confirmation      h...
describe User do    describe "#send_password_reset" do      let(:user) { Factory(:user) }        it "generates a unique pa...
describe User do    describe "#send_password_reset" do      let(:user) { Factory(:user) }        it "generates a unique pa...
describe User do    describe "#send_password_reset" do      let(:user) { Factory(:user) }       it "generates a unique pas...
describe User do    describe "#send_password_reset" do      let(:user) { Factory(:user) }       it "generates a unique pas...
describe User do    describe "#send_password_reset" do      let(:user) { Factory(:user) }        it "generates a unique pa...
Escrever specsisoladas para AR é      difícil
ActiveRecord                  ==          Repositório (classe)            Model (objeto)            BD (reflection)AR faz c...
Uncle Bob:             “ActiveRecord is a              Data Structure”                         http://goo.gl/OEBvXAR deve ...
validações                       associações                          finders                        nada maisAR deve ser u...
Comece pelo               comportamentoVamos fazer diferente. Primeiro, identificamos o comportamento desejado.
describe UserAuthentication do   let(:user) { Factory(:user) }   let(:password) { "123456" }    context "with valid creden...
class UserAuthentication      def initialize(username, password)        @username = username        @password = password  ...
class UserAuthentication      def initialize(username, password)        @username = username        @password = password  ...
“The negative effects on testability in the Active Record pattern can be   minimized by usingmocking or dependency        i...
object doubles são                essenciaisYAY for mocks, stubs, spies, proxies and friends!
BDD == designEu costumava ser da turma do “mocks e stubs são apenas para isolamento de sistemasexternos (como gateways) pq...
Testes quebradiços                   ==              Design ruimAté que tomei vergonha na cara e fui estudar essa bagaça! ;)
object doubles                 +       dependency injectionAtravés disso conseguimos: testes rápidos, objetos desacoplados...
class UserAuthentication   def initialize(username, password)     @username = username     @password = password   end   de...
class UserAuthentication  def initialize(username, password)    @username = username    @password = password  end  def aut...
describe UserAuthentication do  let(:user) { double("an user").as_null_object }  let(:user_repo) { double("an user reposit...
describe UserAuthentication do    let(:user) { double("an user").as_null_object }    let(:user_repo) { double("an user rep...
describe UserAuthentication do  let(:user) { double("an user").as_null_object }  let(:user_repo) { double("an user reposit...
context "with valid credentials" do      before(:each) { encryption_engine.                            stub(:hash_secret)....
context "with valid credentials" do      before(:each) { encryption_engine.                             stub(:hash_secret)...
context "with invalid credentials" do  before(:each) { encryption_engine.                            stub(:hash_secret).  ...
context "with invalid credentials" do  before(:each) { encryption_engine.                            stub(:hash_secret).  ...
describe MyBCryptAdapter do       context "encrypting text with a salt" do         it "respects the lib protocol" do      ...
describe MyBCryptAdapter do       context "encrypting text with a salt" do         it "respects the lib protocol" do      ...
def authenticate(user_repo = User,                 encryption_engine = MyBCryptAdapter)  if user = user_repo.find_by_usern...
Até onde?Quanto de abstração vale a pena? Indireção em excesso é tão ruim quanto alto acoplamento.A dica é abstrair quando...
def authenticate(encryption_engine = MyBCryptAdapter)     if user = User.find_by_username(@username)     ...    endPor ex:...
Mudanças...E se precisarmos mudar o algoritmo de criptografia?
describe MyZYCryptAdapter do  context "encrypting text with a salt" do    it "respects the lib protocol" do      ZYCrypt::...
def authenticate(user_repo = User,                 encryption_engine = MyZYCryptAdapter)  if user = user_repo.find_by_user...
WIN! o/
Mais uma alteraçãoLogging!
def authenticate(user_repo = User,                     encryption_engine = MyBCryptAdapter,                     logger = M...
context "with invalid credentials" do   ...   it "logs the authentication attempt" do     logger = double("a logger")     ...
context "with invalid credentials" do   ...   it "logs the authentication attempt" do     logger = double("a logger")     ...
context "with valid credentials" do   ...   it "doesn’t log the authentication attempt" do     logger = double("a logger")...
context "with valid credentials" do   ...   it "doesn’t log the authentication attempt" do     logger = double("a logger")...
SintomasBDD é uma ótima forma de apontar problemas com o design do código - os sintomascostumam ser claros
Muitos mocks/stubs           numa mesma            dependência                 ==            superfície de           conta...
Superfície de  contato
class BlogController < ApplicationController  def index    @posts = Post.published.page params[:page]    @posts_grouped_by...
tha fuuuuck??!?!?!
class BlogController < ApplicationController  def index    @posts = Post.published.page params[:page]    @posts_grouped_by...
Controller:         quanto mais “burro”,               melhorMinha sugestão para esse caso seria extrair toda essa “filtrag...
Muitos contextosem diferentes níveis    de abstração         ==       muitas responsabilidades
describe User do  context "persistence logic" do    it "validates ..."  end  context "data gathering" do    it "finds reco...
describe User do      context "persistence logic" do        it "validates ..."      end       context "data gathering" do ...
DicasAlgumas formas rápidas de verificar se seu código está “sólido” :D
Pequenas peças de            comportamento              facilmente               acessíveisIsso garante que não precisemos...
app console            .buy(user, product,                   cart)Dica: abra o console da sua aplicação e veja se os proce...
Modele processos, não se prenda apenas a entidades.
class Customer      def initialize(user, supplier)        @user = user        @supplier = supplier      end      def pay(a...
Dont mock types               you dont own                  Write wrappersEvite ao máximo colocar dublês em tipos externos...
“Always check code          in better than you           checked it out.”                         — Uncle BobSeja um bom m...
Crie o hábito de       passardependências como    parâmetros
“Não escreva ‘fat   models’”             — OOP
Próximos passosNão basta apenas alguns slides pra mostrar como fazer isso. É preciso ler, estudar e praticar.Por isso, seg...
Uncle Bob               Michael Feathers                Corey Haines               Gary Bernhardt                 Pat Madd...
Ótimas guidelines (!= regras)
Obrigado    @lucashungarogithub.com/lucashungarolucashungaro@gmail.com
Upcoming SlideShare
Loading in …5
×

SOLID através de BDD: um guia prático para rubistas

2,880 views

Published on

Palestra apresentada na RubyConf Brasil 2011, Dev in Sampa 2011, TDC Florianópolis 2011 e Dev in Vale 2011.

Aborda aplicações práticas dos princípios Single Responsibility e Dependency Inversion, além de dicas de como identificar problemas no design do código orientado a objetos.

Published in: Technology
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,880
On SlideShare
0
From Embeds
0
Number of Embeds
795
Actions
Shares
0
Downloads
35
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

SOLID através de BDD: um guia prático para rubistas

  1. 1. SOLID através de BDD um guia prático para rubistas Lucas Húngaro software developer
  2. 2. SOLIDConjunto de princípios desenvolvidos por Bob Martin que devem ser aplicados para melhorara qualidade do código orientado a objetos.
  3. 3. Rails, MVCRails, MVC e facilitam muito a vida do desenvolvedor, principalmente em aplicações simples.Mas também deixamos de prestar atenção à aspectos importantes enquanto produzimoscódigo rapidamente.
  4. 4. Fat Models aka programação proceduralAssim acabamos desenvolvendo alguns anti-patterns. Pior do que isso é quando algunsdesses anti-patterns são vistos como boas práticas mas, na verdade, são apenas atalhosenganosos (parecem vantajosos a princípio, mas acabam aumentando o custo demanutenção)
  5. 5. OOP, BDD, SOLIDAs soluções são simples mas, muitas vezes, acabam ficando de lado porque a maioria dosdesenvolvedores pensam que são assuntos chatos.
  6. 6. Acadêmico... (chato)Um dos motivos para isso é a origem acadêmica, onde muitas vezes o assunto é discutidoapenas na esfera teórica, com poucos exemplos de aplicação.
  7. 7. Coisa de Javeiro...Outro problema é que muitos associam essas práticas à plataformas como Java e .NET que,infelizmente, remetem a sentimentos de excesso de burocracia e baixa produtividade.
  8. 8. Linguagem dinâmicaMas, para nossa sorte, utilizar esses princípios em linguagens dinâmicas é muito mais fácil emenos burocrático.
  9. 9. SRP e DIPPra facilitar as coisas, vamos falar apenas de dois princípios: Single Responsibility eDependency Inversion - os que acredito causarem o maior impacto
  10. 10. Coesão e Acoplamento“Traduzindo” esses princípios, identificamos que eles falam sobre duas características docódigo: coesão e acoplamento.
  11. 11. Baixa coesão: executa parte de uma responsabilidade ou mais de umaProblemas que queremos eliminar
  12. 12. Alto acoplamento: código preso a um caso de uso e suas dependênciasProblemas que queremos eliminar
  13. 13. Code!Exemplos
  14. 14. Processo usual:
  15. 15. rails new myapp
  16. 16. migrations
  17. 17. finders
  18. 18. data-centric apps fat modelsComeçamos pelos dados (schema) e depois tentamos derivar algum comportamento disso,resultando em objetos “gordos”, pouco coesos e muito acoplados.
  19. 19. Rails apps == model User gigante mais algumas classes sem importânciaDomínios anêmicos
  20. 20. class User < ActiveRecord::Base attr_accessible :email, :password, :password_confirmation has_secure_password validates_presence_of :password, :on => :create def send_password_reset generate_token(:password_reset_token) self.password_reset_sent_at = Time.zone.now save! UserMailer.password_reset(self).deliver end def generate_token(column) begin self[column] = SecureRandom.urlsafe_base64 end while User.exists?(column => self[column]) end endExemplo clássico (railscasts 275). Falta coesão, sobra acoplamento.
  21. 21. class User < ActiveRecord::Base attr_accessible :email, :password, :password_confirmation has_secure_password validates_presence_of :password, :on => :create def send_password_reset generate_token(:password_reset_token) self.password_reset_sent_at = Time.zone.now save! UserMailer.password_reset(self).deliver end def generate_token(column) begin self[column] = SecureRandom.urlsafe_base64 end while User.exists?(column => self[column]) end endDependências
  22. 22. class User < ActiveRecord::Base attr_accessible :email, :password, :password_confirmation has_secure_password validates_presence_of :password, :on => :create def send_password_reset generate_token(:password_reset_token) self.password_reset_sent_at = Time.zone.now save! UserMailer.password_reset(self).deliver end def generate_token(column) begin self[column] = SecureRandom.urlsafe_base64 end while User.exists?(column => self[column]) end endDependências
  23. 23. class User < ActiveRecord::Base attr_accessible :email, :password, :password_confirmation has_secure_password validates_presence_of :password, :on => :create def send_password_reset generate_token(:password_reset_token) self.password_reset_sent_at = Time.zone.now save! UserMailer.password_reset(self).deliver end def generate_token(column) begin self[column] = SecureRandom.urlsafe_base64 end while User.exists?(column => self[column]) end endDependências
  24. 24. describe User do describe "#send_password_reset" do let(:user) { Factory(:user) } it "generates a unique password_reset_token each time" do user.send_password_reset last_token = user.password_reset_token user.send_password_reset user.password_reset_token.should_not eq(last_token) end it "saves the time the password reset was sent" do user.send_password_reset user.reload.password_reset_sent_at.should be_present end it "delivers email to user" do user.send_password_reset last_email.to.should include(user.email) end end endEstrutural
  25. 25. describe User do describe "#send_password_reset" do let(:user) { Factory(:user) } it "generates a unique password_reset_token each time" do user.send_password_reset last_token = user.password_reset_token user.send_password_reset user.password_reset_token.should_not eq(last_token) end it "saves the time the password reset was sent" do user.send_password_reset user.reload.password_reset_sent_at.should be_present end it "delivers email to user" do user.send_password_reset last_email.to.should include(user.email) end end endEstrutural
  26. 26. describe User do describe "#send_password_reset" do let(:user) { Factory(:user) } it "generates a unique password_reset_token each time" do user.send_password_reset last_token = user.password_reset_token user.send_password_reset user.password_reset_token.should_not eq(last_token) end it "saves the time the password reset was sent" do user.send_password_reset user.reload.password_reset_sent_at.should be_present end it "delivers email to user" do user.send_password_reset last_email.to.should include(user.email) end end endDependente de banco de dados == lento
  27. 27. describe User do describe "#send_password_reset" do let(:user) { Factory(:user) } it "generates a unique password_reset_token each time" do user.send_password_reset last_token = user.password_reset_token user.send_password_reset user.password_reset_token.should_not eq(last_token) end it "saves the time the password reset was sent" do user.send_password_reset user.reload.password_reset_sent_at.should be_present end it "delivers email to user" do user.send_password_reset last_email.to.should include(user.email) end end endMuitas responsabilidades (isso porque o “has_secure_password” já esconde outras)
  28. 28. describe User do describe "#send_password_reset" do let(:user) { Factory(:user) } it "generates a unique password_reset_token each time" do user.send_password_reset last_token = user.password_reset_token user.send_password_reset user.password_reset_token.should_not eq(last_token) end it "saves the time the password reset was sent" do user.send_password_reset user.reload.password_reset_sent_at.should be_present end it "delivers email to user" do user.send_password_reset last_email.to.should include(user.email) end end endSpecs lentas, código “rígido” (difícil de modificar), custo de manutenção alto.
  29. 29. Escrever specsisoladas para AR é difícil
  30. 30. ActiveRecord == Repositório (classe) Model (objeto) BD (reflection)AR faz coisas demais e quebra o SRP por design
  31. 31. Uncle Bob: “ActiveRecord is a Data Structure” http://goo.gl/OEBvXAR deve ser usado como estrutura de dados para não se tornar um “buraco negro” decomportamento. Minha guideline: AR contém apenas validação, associações e finders, nadamais.
  32. 32. validações associações finders nada maisAR deve ser usado como estrutura de dados para não se tornar um “buraco negro” decomportamento. Minha guideline: AR contém apenas validação, associações e finders, nadamais.
  33. 33. Comece pelo comportamentoVamos fazer diferente. Primeiro, identificamos o comportamento desejado.
  34. 34. describe UserAuthentication do let(:user) { Factory(:user) } let(:password) { "123456" } context "with valid credentials" do subject { UserAuthentication.new(user.username, password) } it "allows access" do subject.authenticate.should be_true end end context "with invalid credentials" do subject { UserAuthentication.new(user.username, "invalid") } it "denies access" do subject.authenticate.should be_false end end endIsso é o que eu quero que faça
  35. 35. class UserAuthentication def initialize(username, password) @username = username @password = password end def authenticate if user = User.find_by_username(@username) user.password_hash == BCrypt::Engine.hash_secret(@password, user.password_salt) else false end end endUma primeira implementação
  36. 36. class UserAuthentication def initialize(username, password) @username = username @password = password end def authenticate if user = User.find_by_username(@username) user.password_hash == BCrypt::Engine.hash_secret(@password, user.password_salt) else false end end endMelhoramos quanto à coesão... mas ainda há acoplamento
  37. 37. “The negative effects on testability in the Active Record pattern can be minimized by usingmocking or dependency injection” Wikipedia
  38. 38. object doubles são essenciaisYAY for mocks, stubs, spies, proxies and friends!
  39. 39. BDD == designEu costumava ser da turma do “mocks e stubs são apenas para isolamento de sistemasexternos (como gateways) pq geram testes quebradiços quando usados internamente”
  40. 40. Testes quebradiços == Design ruimAté que tomei vergonha na cara e fui estudar essa bagaça! ;)
  41. 41. object doubles + dependency injectionAtravés disso conseguimos: testes rápidos, objetos desacoplados e coesos, custo demanutenção reduzido.
  42. 42. class UserAuthentication def initialize(username, password) @username = username @password = password end def authenticate(user_repo = User, encryption_engine = BCrypt::Engine) if user = user_repo.find_by_username(@username) user.password_hash == encryption_engine. hash_secret(@password, user.password_salt) else false end end endComo estamos aprendendo, vou inverter as coisas e mostrar a implementação primeiro: umaforma de utilizar o DIP é passar as dependências como parâmetros.
  43. 43. class UserAuthentication def initialize(username, password) @username = username @password = password end def authenticate(user_repo = User, encryption_engine = BCrypt::Engine) if user = user_repo.find_by_username(@username) user.password_hash == encryption_engine. hash_secret(@password, user.password_salt) else false end endend
  44. 44. describe UserAuthentication do let(:user) { double("an user").as_null_object } let(:user_repo) { double("an user repository") } let(:encryption_engine) { double("an encryption engine") } before(:each) do user.stub(:password_hash).and_return "the hash" user_repo.stub(:find_by_username).and_return user end
  45. 45. describe UserAuthentication do let(:user) { double("an user").as_null_object } let(:user_repo) { double("an user repository") } let(:encryption_engine) { double("an encryption engine") } before(:each) do user.stub(:password_hash).and_return "the hash" user_repo.stub(:find_by_username).and_return user endSão objetos dublês, não me importo se stub ou mock (ou outro tipo). Essas decisões tomosobre mensagens (métodos), não sobre o objeto todo. Isso é uma feature muito legal doframework de mocks do RSpec
  46. 46. describe UserAuthentication do let(:user) { double("an user").as_null_object } let(:user_repo) { double("an user repository") } let(:encryption_engine) { double("an encryption engine") } before(:each) do user.stub(:password_hash).and_return "the hash" user_repo.stub(:find_by_username).and_return user end
  47. 47. context "with valid credentials" do before(:each) { encryption_engine. stub(:hash_secret). and_return user.password_hash } subject { UserAuthentication.new("username", "123456") } it "allows access" do subject.authenticate(user_repo, encryption_engine).should be_true end endE agora as specs: sem banco de dados, dependências injetáveis, código simples. No fim dascontas, tudo o que preciso é de três objetos que respondam a uma interface bem definida.
  48. 48. context "with valid credentials" do before(:each) { encryption_engine. stub(:hash_secret). and_return user.password_hash } subject { UserAuthentication.new("username", "123456") } it "allows access" do subject.authenticate(user_repo, encryption_engine).should be_true end endE agora as specs: sem banco de dados, dependências injetáveis, código simples. No fim dascontas, tudo o que preciso é de três objetos que respondam a uma interface bem definida.
  49. 49. context "with invalid credentials" do before(:each) { encryption_engine. stub(:hash_secret). and_return "another hash" } subject { UserAuthentication.new("username", "invalid") } it "denies access" do subject.authenticate(user_repo, encryption_engine).should be_false endend
  50. 50. context "with invalid credentials" do before(:each) { encryption_engine. stub(:hash_secret). and_return "another hash" } subject { UserAuthentication.new("username", "invalid") } it "denies access" do subject.authenticate(user_repo, encryption_engine).should be_false endend
  51. 51. describe MyBCryptAdapter do context "encrypting text with a salt" do it "respects the lib protocol" do BCrypt::Engine.expects(:hash_secret) MyBCryptAdapter.encrypt("text", "salt") end end end class MyBCryptAdapter def self.encrypt(plain_text, salt) BCrypt::Engine.hash_secret(plain_text, salt) end endPodemos abstrair ainda mais...
  52. 52. describe MyBCryptAdapter do context "encrypting text with a salt" do it "respects the lib protocol" do BCrypt::Engine.expects(:hash_secret) MyBCryptAdapter.encrypt("text", "salt") end end end class MyBCryptAdapter def self.encrypt(plain_text, salt) BCrypt::Engine.hash_secret(plain_text, salt) end end... e usar um mock para garantir a interface.
  53. 53. def authenticate(user_repo = User, encryption_engine = MyBCryptAdapter) if user = user_repo.find_by_username(@username) user.password_hash == encryption_engine. encrypt(@password, user.password_salt) else false endend
  54. 54. Até onde?Quanto de abstração vale a pena? Indireção em excesso é tão ruim quanto alto acoplamento.A dica é abstrair quando é um componente que mudará muito ou quando você não tem amínima ideia disso, pois isso preserva seu “direito” de mudar caso seja necessário.
  55. 55. def authenticate(encryption_engine = MyBCryptAdapter) if user = User.find_by_username(@username) ... endPor ex: caso eu tenha certeza de que meu repositório de usuários será sempre um modelo AR(e nunca precisarei buscá-los em um LDAP, por exemplo), podemos eliminar essa injeção edeixar acoplado.
  56. 56. Mudanças...E se precisarmos mudar o algoritmo de criptografia?
  57. 57. describe MyZYCryptAdapter do context "encrypting text with a salt" do it "respects the lib protocol" do ZYCrypt::Engine::Passwords. should_receive(:hash_password_with_salt) MyZYCryptAdapter.encrypt("text", "salt") end endendclass MyZYCryptAdapter def self.encrypt(plain_text, salt) ZYCrypt::Engine::Passwords. hash_password_with_salt(plain_text, salt) endend
  58. 58. def authenticate(user_repo = User, encryption_engine = MyZYCryptAdapter) if user = user_repo.find_by_username(@username) user.password_hash == encryption_engine. encrypt(@password, user.password_salt) else false endend
  59. 59. WIN! o/
  60. 60. Mais uma alteraçãoLogging!
  61. 61. def authenticate(user_repo = User, encryption_engine = MyBCryptAdapter, logger = MyFancyLogger) ... endPassando como parâmetro
  62. 62. context "with invalid credentials" do ... it "logs the authentication attempt" do logger = double("a logger") logger.should_receive(:log).with("something") subject.authenticate(user_repo, encryption_engine, logger) end endUm caso de uso meio forçado, apenas como exemplo. Vamos verificar as interações entre oscomponentes. O “como” fica à cargo do teste unitário do logger, não do autenticador.
  63. 63. context "with invalid credentials" do ... it "logs the authentication attempt" do logger = double("a logger") logger.should_receive(:log).with("something") subject.authenticate(user_repo, encryption_engine, logger) end endUm caso de uso meio forçado, apenas como exemplo. Vamos verificar as interações entre oscomponentes. O “como” fica à cargo do teste unitário do logger, não do autenticador.
  64. 64. context "with valid credentials" do ... it "doesn’t log the authentication attempt" do logger = double("a logger") logger.should_receive(:log).never subject.authenticate(user_repo, encryption_engine, logger) end endUm caso de uso meio forçado, apenas como exemplo. Vamos verificar as interações entre oscomponentes. O “como” fica à cargo do teste unitário do logger, não do autenticador.
  65. 65. context "with valid credentials" do ... it "doesn’t log the authentication attempt" do logger = double("a logger") logger.should_receive(:log).never subject.authenticate(user_repo, encryption_engine, logger) end endUm caso de uso meio forçado, apenas como exemplo. Vamos verificar as interações entre oscomponentes. O “como” fica à cargo do teste unitário do logger, não do autenticador.
  66. 66. SintomasBDD é uma ótima forma de apontar problemas com o design do código - os sintomascostumam ser claros
  67. 67. Muitos mocks/stubs numa mesma dependência == superfície de contato muito amplaEssa é uma das principais reclamações dos desenvolvedores que são contra o uso pesado dedublês - criar muitos mocks/stubs nos setups dos cenários de testes. A questão é que isso,na verdade, está revelando problemas com o design.Exemplo: teste de controller fazendo stub de vários métods de um model => falta deencapsulamento e model quebrando SRP
  68. 68. Superfície de contato
  69. 69. class BlogController < ApplicationController def index @posts = Post.published.page params[:page] @posts_grouped_by_year = Post. all. group_by {|post| post. created_at. beginning_of_year } @posts_highlights = Post.published.featured.limit(3) @categories = Category.includes(:posts) @faqs = Faq.tagged_with(@posts.map {|post| post.tag_list}. join(","). split, :any => true) endend
  70. 70. tha fuuuuck??!?!?!
  71. 71. class BlogController < ApplicationController def index @posts = Post.published.page params[:page] @posts_grouped_by_year = Post. all. group_by {|post| post. created_at. beginning_of_year } @posts_highlights = Post.published.featured.limit(3) @categories = Category.includes(:posts) @faqs = Faq.tagged_with(@posts.map {|post| post.tag_list}. join(","). split, :any => true) endend
  72. 72. Controller: quanto mais “burro”, melhorMinha sugestão para esse caso seria extrair toda essa “filtragem” para uma classeespecializada em montar a página inicial do blog (poderia ser utilizado um Presenter).
  73. 73. Muitos contextosem diferentes níveis de abstração == muitas responsabilidades
  74. 74. describe User do context "persistence logic" do it "validates ..." end context "data gathering" do it "finds records under certain conditions ..." end context "making payments" do it "register an error in case the key is invalid" it "writes some info to the log in case of success" # ... endend
  75. 75. describe User do context "persistence logic" do it "validates ..." end context "data gathering" do it "finds records under certain conditions ..." end context "making payments" do it "register an error in case the key is invalid" it "writes some info to the log in case of success" # ... end endIsso nem sempre é “exato”, mas pode ser um ótimo indicativo de problemas.
  76. 76. DicasAlgumas formas rápidas de verificar se seu código está “sólido” :D
  77. 77. Pequenas peças de comportamento facilmente acessíveisIsso garante que não precisemos de setups muito elaborados e nos “força” a abstrairconceitos de negócio em forma de código.
  78. 78. app console .buy(user, product, cart)Dica: abra o console da sua aplicação e veja se os processos de negócio podem serexecutados facilmente na linha de comando
  79. 79. Modele processos, não se prenda apenas a entidades.
  80. 80. class Customer def initialize(user, supplier) @user = user @supplier = supplier end def pay(amount, gateway = SomeGatewayAdapter) ... end endExemplo: User assume o papel Customer para o processo de pagamento.
  81. 81. Dont mock types you dont own Write wrappersEvite ao máximo colocar dublês em tipos externos. Caso necessário, crie um wrapper/adapter
  82. 82. “Always check code in better than you checked it out.” — Uncle BobSeja um bom menino! :P
  83. 83. Crie o hábito de passardependências como parâmetros
  84. 84. “Não escreva ‘fat models’” — OOP
  85. 85. Próximos passosNão basta apenas alguns slides pra mostrar como fazer isso. É preciso ler, estudar e praticar.Por isso, seguem algumas referências.
  86. 86. Uncle Bob Michael Feathers Corey Haines Gary Bernhardt Pat Maddox Avdi GrimmEsses são apenas alguns nomes, que levarão a outros. Há muita gente altamente capacitadafalando sobre e praticando essas técnicas.
  87. 87. Ótimas guidelines (!= regras)
  88. 88. Obrigado @lucashungarogithub.com/lucashungarolucashungaro@gmail.com

×