The entire time I’ve been using FactoryBot, several years at this point, I’ve used it one factory at a time:

company = create(:company, name: "Acme, Inc.")
alice = create(:user, name: "Alice Smith")
posts = create_list(:post, 3, user: alice)

Do you see the mistake I make all the dang time? Spoiler alert, I forgot the company relation on Alice’s user, so she is either orphaned (unfortunate) or created on an entirely unrelated company. That’s gonna make my test fail in weird ways!

Lately, I’ve been trying something different: create the whole object graph I want to test on in one fell swoop:

company = create(
  :company,
  name: "Acme, Inc",
  user: build(
    :user, 
    name: "Alice Smith",
    posts: build_list(:post, 3)
  )
)

The entire intent of the test scenario is made clear right here. And, the error I so often make is solved structurally rather than by vigilance.

Granted, that’s pretty chunky and way more lines. I feel like it’s a worthy tradeoff!

When I need to reference the models created by my jumbo object graph, I use RSpec let and ActiveRecord finders with a mind towards consistently finding the right thing:

let(:company) do
  create(...) # the whole company bit from above
end
let(:alice) { company.users.find_by(name: "Alice Smith") }
let(:posts) { alice.posts }

Here’s a real dinger of a sentence from Michael Lopp’s latest, The Art of Leadership: Small Things, Done Well:

Failure is created by the increasing entropy of a growing number of humans running around the building, good intentions in hand, breaking things.

Growing an organization requires rethinking trust, coordination, and collaboration. The breakpoints where things go from working pretty well to an absolute shamble come faster than we think. They don’t even occur at nice, round numbers like base–2 or base–10 orders of magnitude.

Figuring out how this works for teams, companies, social networks, and whole countries feels like one of the big unsolved problems of the knowledge/attention-era.

Writing clarifies thinking. Therefore, writing design docs clarifies one’s thinking about code. Design Docs at Google and an example/meta design doc from the same author are great places to start!

I found that writing prose until I run out of clarity and then switching to proof-of-concept code is even better. The constraint of making an ambitious design work with a minimal change-set is a nice way to work for a day or so.

Lots of features or fixes don’t require in-depth thinking to get started. But when they do, sorting out the ideas and tradeoffs in writing helps a lot.

Write until I run out of ideas, flesh those ideas out, write about the nuances I found. It’s a nice feedback loop!

A Better Approach to 360° Feedback: Bradford Fults shares ways to route around fallible human memory and gather useful information when it comes to review season.

Humans also have a recency bias and suffer from long-term memory distortions that change to fit their current opinions of other people. This means that “observations” from months ago often aren’t so much observations as they are current opinions and emotions repackaged as fixed stories about the past. Most people don’t even intend to distort the truth like this: it’s just the way the human brain works.

Instead, ask questions in the context of how the reviewer works with the reviewed, particularly in the last 90 days or so. Paraphrasing Janet Jackson: “What Have You Done For Me Lately?”