porcelli

Intro

Vou iniciar este post com uma breve visão do que EU entendo sobre os principais XDD para em seguida discutir o motivo pelo qual não os acho relevante. Gostaria também de ressaltar que posso SIM ter uma visão limitada ou equivocada destes XDD’s, porém não vamos minimizar esta discussão com argumentos simplórios como “falta de conhecimento”, “falta de prática” ou coisas do gênero... pois o que será discutido aqui é um pouco mais conceitual e filosófico do que as técnicas/processos em si.

Com isso dito, vamos lá:

TDD (Test-driven development)

Esta técnica (ou processo) que visa obter uma maior qualidade na arquitetura/código, pois guindo o desenvolvimento por testes além de se ter um resultado mais assertivo, você também obtém uma arquitetura desacoplada. Geralmente se aplica este processo (NovoTeste->Falha->Implantação->Sucesso->NovoTeste...) em pequenos ciclos.

Meu ponto de vista:

nicholasjhenry

class AddComment
  attr_reader :observer, :store, :success, :fail

  def initializer(observer, store)
    @observer, @store = observer, store
    yield self if block_given?
    return self
  end

  def call(post_id, comment_attrs)

jch

# A Sidekiq background job worker tha knows how to render Rails views
# Don't worry, I *think* I know what I'm doing ;)
class RenderWorker < AbstractController::Base
  include AbstractController::Rendering
  include AbstractController::Logger  # dependency from actionview calling logging
  include Rails.application.routes.url_helpers
  include Sidekiq::Worker
  
  append_view_path "#{Rails.root}/app/views"  # from AbstractController::ViewPaths

steveclarke

Capybara

save_and_open_page

Matchers

have_button(locator)

henrik

tmux cheatsheet

As configured in my dotfiles.

start new:

tmux

start new with session name:

jasonrudolph

"Why You Don't Get Mock Objects" by Gregory Moeck

RubyConf 2011 | 2011-09-29 | Gregory Moeck (@gregmoeck) | Slides

• Recommended as the best book on mocks: Growing Object-Oriented Software, Guided by Tests by Steve Freeman & Nat Pryce
• Common arguments against mocks
  • They duplicate implementation
  • They lead to brittle tests
• Mock objects + procedural programming = bad idea
• If you're doing traditional Rails development (which tends to follow more of a "procedural", do-this-and-then-do-that style), mock objects probably aren't for you

juggy

# create the template
template = PageOfflineTemplate.new
template.quote = quote
template.pages = quote.build_pages
        
# Here I render a template with layout to a string then a PDF
pdf = PDFKit.new template.render_to_string(:template=>"quotes/review.html.haml")
        

hubertlepicki

class HelloWorldController < AbstractController::Base
  include AbstractController::Rendering
  include AbstractController::Layouts
  include AbstractController::Helpers
  include AbstractController::Translation
  include AbstractController::AssetPaths
  include ActionController::UrlWriter

  # Uncomment if you want to use helpers defined in ApplicationHelper in your views
  # helper ApplicationHelper

josevalim

# In your test_helper.rb
class ActiveRecord::Base
  mattr_accessor :shared_connection
  @@shared_connection = nil

  def self.connection
    @@shared_connection || retrieve_connection
  end
end

ghoseb

;;
;; NS CHEATSHEET
;;
;; * :require makes functions available with a namespace prefix
;;  and optionally can refer functions to the current ns.
;;
;; * :import refers Java classes to the current namespace.
;;
;; * :refer-clojure affects availability of built-in (clojure.core)
;;   functions.