Hello,
This week, I spent time writing about testing, sharing my approach with git worktrees, and exploring various options to compare times in tests without including milliseconds.
The week started with publishing the Short Ruby Newsletter - edition 151. I forget again to celebrate the 150 editions so far 🙂. Soon we will celebrate passing 6000 subscribers (we are 50 short yet).
I started putting a bit of time into exploring another passion of mine, creative problem solving, and I (re)started reading some papers about it:
"The process of creativity is not easily come by, nor are all of its phases easy to endure. We should then perhaps be prepared to discover that those who have high potential as well as those who have demonstrated true creativity will show a disposition to undertake problems where the degree of difficulty and frustration is great and will have a drive toward completion and accomplishment that is persistently strong."
Development and Testing
Not all tests written with TDD belong in your codebase
TDD is a development practice, not a test design technique.After writing code through TDD, don’t keep every test keep only those that:
Verify requirements → prove your code does what it’s supposed to.
Document behavior → help future developers understand or debug.
Protect structure → ensure critical architectural rules or interfaces.
Delete tests that were just scaffolding, explore APIs, or verify internal details, they helped you design, but they no longer deliver lasting value. I expanded this into an article about “The Art of Knowing Which TDD Tests to Delete”
Development
How I use git worktrees
I've been using git worktree for at least five years now. Here's how I set things up:
➤ pwd
/Users/lucian/projects/short_ruby
➤ ls
main
pairing
feature_real_author
➤ cd main ; git worktree list
/short_ruby/main 7d6877a [main]
/short_ruby/pairing db66195 [lg/add-thread-support-for-bluesky]
/short_ruby/feature_real_author 78165e1 [lg/real-author-in-view]I like to keep the main for being able to quicly check it when I need and diff if required, I keep the pairing for locally checking other branches when I review them and then specific folders for various feature. Read more about my approach at How I use git worktree
Ruby on Rails
Avoid Errors in Time Comparison Tests
I explored various ways to do time comparison when working with Ruby and Ruby on Rails and want to ignore miliseconds:
Time.current.change(usec: 0)
# 2025-10-10 22:22:29.000000000 EEST +03:00
Time.current.to_i
# 1760124164
Time.current.round
# 2025-10-10 22:22:51.000000000 EEST +03:00
Time.current.iso8601
# "2025-10-10T22:23:08+03:00"
Time.current.to_fs(:iso8601)
# "2025-10-10T22:23:16+03:00"But you can also use specific helpers in RSpec and Minitest:
expect(time).to be_within(1).of(other_time)
assert_in_delta(time, other_time, 1.0)Read the full article with examples at How to avoit pitfalls when comparing time in Ruby
Good Enough Testing Workshop
Good tests begin with good samples.
You can’t test everything, but you can test a representative subset that matters. Think like a statistician: sample across boundaries, cover each risk area, and avoid bias.
Synthetic data helps you test logic cleanly and deterministically.
Realistic data reveals integration issues, performance surprises, and messy real-world inputs.
You need both. I wrote more about why Good Tests Begin with Good Samples
Ruby
New resources on Hanami
There seems to have been some new resources about Hanami:
Ben Sheldon wrote about Hanami and loading code, faster
Andrea Fomera published a new repository hanami-omakase - “A curated set of defaults for Hanami.rb“
Brooke Kuhlmann wrote about Hanami Container
Ryan Bigg published a couple of articles as a tutorial series about Hanami for Rails Developers: Part 3: Forms
On my mind
I’ve been thinking about clarity and how it shows up in code, tests, and writing. Deciding when to delete a test, comparing two times without noise, or trying to keep myself to not make another long newsletter are all about understanding what truly matters and letting go of what doesn’t. It is easy to explain it but being and doing it take a lot more practice.
I started transforming the workshop that I did at EuRuKo about testing and LLMs into a public one that would be about reliable generating test cases using LLMs
Next week I will start recording the video version of the current Good Enough Testing workshop. Let’s see how it goes.