jdickey

source 'https://rubygems.org'

gem 'rails', '3.2.12'

# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'

gem 'sqlite3'

# gem 'haml'

jdickey

#!/usr/bin/env ruby

require 'git'
require 'logger'

BASE_SUBDIR  = '/src/rails'

$logger = Logger.new STDOUT
$logger.level = Logger::INFO

jdickey

Here follow two versions of a Rake task, which was originally created to use with CruiseControl.rb continuous integration.

When running the first, I get a reliable segfault whenever RSpec encounters any sort of error (typo in my code, misnamed/missing file, etc.) With the second, it's been reduced to a Heisenbug of sorts; it only repeats the behaviour once in every 5 to 8 opportunities, but when it does, repeatedly running the Rake task will produce the segfault exactly 5 times and then it stops. Very weird.

jdickey

My app has, among others, an Article model and a User model. The Article model includes the line

belongs_to :author, class_name: 'User'

This would allow me to, for example, get the author's name via anArticle.author.name. The relevant ActiveRecord documentation indicates that :class_name is used to "[s]pecify the class name of the association", and gives a directly relevant example.

By contrast, the :foreign_key option for belongs_to specifies "the foreign key used for the association", but does not affect the name of the association. So, if I had

belongs_to :user, foreign_key: 'author_id'

jdickey

# This file is copied to spec/ when you run 'rails generate rspec:install'
ENV["RAILS_ENV"] ||= 'test'
if ENV['RAILS_ENV'] == 'test'
  require 'simplecov'
  SimpleCov.start 'rails' do
    add_filter '/vendor/'
  end
end

require File.expand_path("../../config/environment", __FILE__)

jdickey

%h1 New contribution

= simple_form_for(new_article_contribution_path(@contribution.article)) do |f|
  = f.error_notification

  .form-inputs

  .form-actions
    = f.button :submit

jdickey

Want to know how brain-dead the scaffolding generator for Rails is? Mind-bogglingly so.

The first of the two files below is what was generated for app/views/contributions/index.html.haml; the second is the corrected version. Bear in mind that the routing had already been adjusted prior to running the generator so that it could have determined that Contributions were nested within Articles, if it had cared to. The generator either didn't look or couldn't deal with nested resources. Either way, serious brain death taking significant time to detect, diagnose and work around was required.

There has to be a better way. Any ideas?

EDIT: Investigating amatsuda/nested_scaffold as more likely to be Useful. nested_scaffold is currently at an 0.2.3 release. Being pre-1.0 (as are many of the Gems we rely on, but that's another rant entirely), it can't be expected to yet be feature-complete, let alone b

jdickey

From a pry session attempting to figure out why Array#count with a block doesn't return the expected value:

[16] pry(#<Article>)> self.contributions
[
    [0] #<Contribution:0x007fbfa8801e10> {
                      :id => 2,
              :article_id => 2,
          :contributor_id => 1,
        :original_content => "Ut enim",

jdickey

#!/usr/bin/env ruby

# findbreaks 0.9
# Script to find all spec files in an `rspec` run that report errors and produce
# a list of all failed spec filenames, with each such listed once. Useful if you
# have numerous specs that break due to a world-changing edit you've just made,
# and you want a nice list of the broken specs without having to read through
# hundreds of lines of RSpec bleeding on your terminal. Pick one; fix it; run
# this again; repeat.
#

jdickey

SOLVED 3 June 2013 15:35 GMT/23.35 SGT

Thank you, +Drew Ulmer, my default DatabaseCleaner setup was indeed the culprit. Changing the strategy to :truncation fixed the problem. Of course, the idea that a database-cleanup utility could FUBAR your spec-automation tool in such a way that valid specs would fail, in your word, non-deterministically, is a Nietzsche incident. ("That which does not kill you makes you stronger.")

UPDATED 3 June 2013 11:08 GMT/19:08 SGT

Sort-of solved; using the exact same spec_helper.rb file as I was using on a different project that successfully deals with feature specs (but not JavaScript testing, yet) got me back to a known point. I've attached the earlier and current spec_helper.rb files for your spelunking pleasure.

Importantly, the spec at line 14 of user_signs_in_and_sees_name_greeting_spec.rb can either work or