Chris Kottom's Tech and Business Blog

Solid Service Objects with Interactor

2025-06-20T09:11:00+02:00

Most non-trivial Rails applications eventually outgrow the basic MVC pattern. You start with simple controller actions and model methods, but as your business logic gets more complex, you need somewhere to put all that code. The choice between fat...

Minitest Assertions with Spec-Style Blocks

2025-06-11T13:52:00+02:00

I just recently started using Minitest again on some greenfield projects after spending several years working primarily in RSpec. Having been over to the other side, I can say there was certainly a mix of things I liked and things I didn’t, but without...

Working in Public Update - September 5, 2022

2022-09-05T02:00:00+02:00

What I’ve been working on

I spent a lot of time last week investing in areas that I think will help me go faster as I build out HuddleUp over the next weeks and months, so even though I didn’t cross as many items off the to-do list as I would have...

Working in Public Update - August 29, 2022

2022-08-29T11:00:00+02:00

I spent the past two weeks in Italy enjoying the sights and sounds and, let’s be honest here, tastes that the country has to offer.

We’ve been taking our family there for the past 13 years - same town, same apartment, same everything - and it’s always been a great source of inspiration as well as a place to catch our breath before the start of school and the final push through the end of the year.

Comparing Timestamps in Rails

2018-01-14T01:00:00+01:00

It’s not old, it’s vintage.

This post was last updated some years ago and hasn’t been updated recently. Be aware that some of the content, tools, and techniques described may not be completely up-to-date.

The Ruby core language and standard library include two classes that represent timestamps: Time and DateTime. And even though they fill similar needs, they have different internals and aren’t comparable.


1
2
3
4
5
6
7
8
9
10
11

irb(main):001:0> require 'date'
true
irb(main):002:0> time = Time.now
2018-01-14 16:40:29 +0100
irb(main):003:0> datetime = DateTime.now
#<DateTime: 2018-01-14T16:40:40+01:00 ((2458133j,56440s,60191240n),+3600s,2299161j)>
irb(main):004:0> time < datetime
ArgumentError: comparison of Time with DateTime failed
        from (irb):5:in `<'
        from (irb):5
        from /home/chris/.rbenv/versions/2.4.2/bin/irb:11:in `<main>'

Rails Helper Testing Made Simple

2017-06-13T02:00:00+02:00

It’s not old, it’s vintage.

This post was last updated some years ago and hasn’t been updated recently. Be aware that some of the content, tools, and techniques described may not be completely up-to-date.

Rails relies on a standard project structure and a strong set of conventions to keep things neat and tidy - models separated from controllers, configuration in another folder structured just so. The exception that proves the rule in this case, though, would have to be Rails view helpers. Helpers tend to be a dumping ground for all the random bits of view logic, formatting, and utility code that accumulate in every web application, and if you’re not disciplined (and most of us aren’t), app/helpers can degenerate into a jungle quickly.

But helpers fill a necessary role in our applications by removing presentation logic from our templates and moving it to methods which makes it easier to test. So even though they’re going to be hard to organize almost by definition, we can still be disciplined about testing them. In other words: your view helpers might still look like spaghetti, but at least we can make sure it’s well-tested spaghetti.

Full-Stack Testing with Rails System Tests

2017-04-26T10:29:46+02:00

It’s not old, it’s vintage.

This post was last updated some years ago and hasn’t been updated recently. Be aware that some of the content, tools, and techniques described may not be completely up-to-date.

Ruby on Rails’ bundled support for automated testing has contributed to building a culture of testing within the community, but it’s also been a source of some debate. Differences in testing styles and preferences have spawned long-running discussions and flame wars over the years. Most of this amounts to bikeshedding, but if there’s one area where The Rails Way has lagged behind RSpec, it’s been in the area of end-to-end application testing. RSpec has long had expressive feature specs based on Capybara, while Rails default integration tests, though functional, have never been as expressive.

With the release of version 5.1, Rails introduces system tests built on Capybara. These look like just the thing to fill this longstanding gap, and the fact that they’ll be configured to work right out of the box with no additional setup required will make it easier for more developers to start using them. In this post, we’re going to look at the approach Rails takes toward system tests and what kind of advantages they offer over both old-school integration tests and current solutions for testing apps with Capybara.

Versioning a Rails API

2017-04-05T02:00:00+02:00

It’s not old, it’s vintage.

This post was last updated some years ago and hasn’t been updated recently. Be aware that some of the content, tools, and techniques described may not be completely up-to-date.

When I finally manage to master an API or framework
by CommitStrip.com

API versioning is one of those topics that divides developers into two camps: those who just know that their way is the best way, and those that are confused by the first camp and would rather pass on the whole thing. Once we set aside the bikeshedding, there are sound, sane justifications for choosing one method over another, but in a lot of cases, discussions move from theoretical to hypothetical problems instead of worrying about making things that work.

The good news for Rails developers is that adding versions to an existing application doesn’t have to be painful. If you know what to do, you can implement it and maintain it with little effort.

In this article, we’ll look at what you get by versioning your API, why you need to think really hard before deciding not to, and how to update your application to make it work.

Minitest Cheat Sheet

2016-08-10T18:28:59+02:00

It’s not old, it’s vintage.

This post was last updated some years ago and hasn’t been updated recently. Be aware that some of the content, tools, and techniques described may not be completely up-to-date.

Recently I came across a post that called out a perceived lack of documentation and learning materials for Minitest in contrast with RSpec. And while I’m not entirely sure I agree with the premise, the main point of the article had the ring of truth to it:

If there’s a problem to be solved here, it’s that the obvious parts of Minitest need to be better documented. Organize the new documentation in the format of “I want to do xyz thing”,with an example.

Bryan Powell

Honestly, what project couldn’t use better docs - more focused, more examples, and detailed explanations? That was exactly the same line of thinking that got me thinking about writing The Minitest Cookbook.

I released a cheat sheet with the book that I thought might provide people with a partial solution, so I prepared a simplified version that includes a reference to the basic methods and syntax for Minitest and Minitest::Spec as well as a full listing of all assertions and expectations for each along with simple code examples for context. (The full version also includes Rails-specific helpers and assertions and a list of the most commonly used Capybara methods.)

Testing Rails Background Workers

2015-11-24T01:00:00+01:00

It’s not old, it’s vintage.

This post was last updated some years ago and hasn’t been updated recently. Be aware that some of the content, tools, and techniques described may not be completely up-to-date.

When it was released in Rails 4.2, Active Job was an important addition to the platform. Background jobs have been a part of the ecosystem for a long time, but this was the first time that developers had a single API to work with a variety of job queuing frameworks. Having a common interface has led to a shared base of knowledge and patterns for developing and testing workers.

In the last post, we looked at some good practices for writing well-designed background jobs in Rails using Active Job, but we didn’t get around to the question of how to test them. This post will focus on a step-by-step strategy for testing all of your application’s “set it and forget it” code - one that leverages the unified Active Job interface and the tools Rails and Minitest provide us.

Bulletproof Rails Background Jobs

2015-11-12T01:00:00+01:00

It’s not old, it’s vintage.

This post was last updated some years ago and hasn’t been updated recently. Be aware that some of the content, tools, and techniques described may not be completely up-to-date.

The ability to run operations with long or uncertain execution times in the background has become a standard tool for modern web applications, and most frameworks and platforms now include some sort of support for encapsulating pieces of logic that involve heavy lifting out of the main request/response cycle. For example, I recently finished work on a relatively simple Rails application that had about a dozen different background jobs written for a whole range of standard-ish use cases:

Sending bulk notifications to a group of users
Consuming data from external APIs and updating the database
Batch creation of work items to users
Importing records from an uploaded data file
Complex object state manipulation that doesn’t fit in an AR callback
Refreshing scores cached in the database after an admin changes the weights used to calculate them

The way I write and test background workers has evolved over the years, and since I’m getting ready to start a new project that will have a big background processing component, I thought it would be a good time to reflect on my approach and what I’ve learned.