mipearson

#!/usr/bin/env ruby

changed = `git diff --numstat origin/master | awk '{ print $3 }' | grep -E '(\\.rb|\\.rake)$'`

changed = changed.split("\n").select { |c| File.exist?(c) }

if changed.length > 0
  system "rubocop #{ARGV.join(' ')} #{changed.join(' ')}"
else
  puts "No changes."

mipearson

# include this mixin (or put the code directly) into your application_controller.rb

module Shared
  module DevelopmentViewResolveCaching
    extend ActiveSupport::Concern

    # Speeds up development view rendering by about ~300ms as we don't need
    # to call the slow view resolver more than once per partial.
    #
    # From https://github.com/rails/rails/issues/20752

mipearson

# Copyright 2018 Marketplacer under the MIT license.
class CapybaraTimers
  class << self
    attr_accessor :nesting, :total_time

    def setup
      # Wrap every DSL method and every matcher with our timing function
      Capybara::Session::DSL_METHODS.each do |name|
        setup_timer_on_method(Capybara::DSL, name)
      end

mipearson

POINTS = {
  "A" => 1, "B" => 3, "C" => 3, "D" => 2,
  "E" => 1, "F" => 4, "G" => 2, "H" => 4,
  "I" => 1, "J" => 8, "K" => 5, "L" => 1,
  "M" => 3, "N" => 1, "O" => 1, "P" => 3,
  "Q" => 10, "R" => 1, "S" => 1, "T" => 1,
  "U" => 1, "V" => 4, "W" => 4, "X" => 8,
  "Y" => 4, "Z" => 10
}

mipearson

POINTS = {
  "A" => 1, "B" => 3, "C" => 3, "D" => 2,
  "E" => 1, "F" => 4, "G" => 2, "H" => 4,
  "I" => 1, "J" => 8, "K" => 5, "L" => 1,
  "M" => 3, "N" => 1, "O" => 1, "P" => 3,
  "Q" => 10, "R" => 1, "S" => 1, "T" => 1,
  "U" => 1, "V" => 4, "W" => 4, "X" => 8,
  "Y" => 4, "Z" => 10
}

mipearson

So far I've been part of four projects and witnessed one that have used Cucumber and automated browser testing (eg selenium). For one reason or another, this has always felt, in retrospect, a waste of time.

I'm going to list the details of the projects here and I'd like others to contribute with their own successes and failures.

I'm doing this as there's a significant contingent in the community who believe that this testing approach is the best way forward. I would like this to be true. Instead, I'm seeing that the toolsets and the knowledge in the community are not mature enough for anything other than simple projects.

This gist was previously about BDD. It's now purely about integration testing using cucumber and using integration tests to drive development. I like BDD as a concept. I have not yet seen it implemented in such a way that made me think the effort was worth the benefit. I think that the current approach and toolsets are to blame for this.

Project 1:

mipearson

class NpmCheck
  # Checks package.json against the local node_modules directory
  # to assert that every package specified in package.json is
  # present in node_modules. If possible, it performs a basic
  # "newer or equal than" check on the package's version. Without
  # access to npm's semver primitizes & parsing it is a bit more difficult
  # to perform proper version matching checks.
  #
  # Requires https://github.com/jlindsey/semantic to parse versions.
  # 

mipearson

--colour
--format ParallelTests::RSpec::SummaryLogger
--format ParallelTests::RSpec::RuntimeLogger --out tmp/parallel_runtime_rspec.log
--format ParallelTests::RSpec::FailuresLogger --out tmp/rspec_failures.log

mipearson

class ApplicationController < ActionController::Base
  # ...

  before_filter :check_for_default_route
  
  class DefaultRouteException < Exception
    # Placeholder exception so that we can report request & person data back
    # to rollbar
  end
    

mipearson

 def with_retries(timeout = 5.seconds, retry_delay: 0.1.seconds, &blk)
    start = Time.now
    begin
      blk.call
    rescue
      if Time.now > start + timeout
        raise
      else
        sleep retry_delay
        retry