For the last 20 years, Rubyists have adopted dozens of tools and technologies that allow us to write better software, scale projects, and ship what needs to be shipped to production the way we want it. I will name just a few of them: Docker, ruby-lsp, AI, RuboCop, MiniTest, RSpec, Cucumber.
The interesting fact, however, is that all these tools faced criticism when they were introduced. Some were heavily criticized, others faced a little skepticism. But the fact is, eventually, we adopted them and now it’s hard to imagine our programming life without them. We no longer argue about spaces or tabs; we just do gem install rubocop and then rubocop -a. We adopted these tools so that we could achieve even more. We delegated part of what we were doing to these artificial electronic helpers.
Think about it. The first version (and some subsequent ones as well) of Ruby on Rails was implemented by DHH in TextMate with just syntax highlighting. No code completion, no linters, no IDEs, no AIs. I remember those days. I was using Notepad++ on Windows for PHP and Ruby development.
As we see across the years, the process of adopting new tools and new ways to help us ship more, faster, and better is endless. If we cannot come up with something internally, like RuboCop, we look elsewhere and adopt things used in other ecosystems like Docker, or MiniTest (which is an adaptation of a Java library).
For the last several years, I have been actively working with JVM languages like Java and Kotlin. When I first started working with them, I was quite irritated by the amount of code and things I needed to do just to run my program. Over time, however, I noticed the significant confidence I gained every time the compiler successfully built my code. It doesn’t guarantee that the code works as I expect, but it already gives me a lot - a full understanding of the data flow and all the connections between various parts of my code. My software may still crash once started, but I’m still certain that a big deal of correctness is already ensured. With a few additional tests, I can make sure the business logic works just as it should.
What about Ruby? Without a single line of tests, you don’t know anything about your code. Do you pass the correct data? Does your business logic even make sense? With simple scripts, you might guess and imagine how the code works, but will you be right? What about a simple refactoring or a feature request where you have no idea what kind of input you’re dealing with? Are they simple primitives like Strings or Integers? Or maybe instances of some classes or, even worse, nested Arrays or Hashes?
The only ways to check this are either to run the code and see, or to write tests. So we go with tests:
- Tests to ensure the code accepts the correct data.
- Tests to ensure the business logic is correct.
- Tests to ensure edge cases won’t cause issues.
Tests are great, don’t get me wrong. But looking at the picture I described above, it seems we rely too much on one single source of confidence. What if they fail? And this happens. What if the tests are wrong? Maybe we stubbed too much and now we’re testing stubs, not the real code. No one will save us then. It looks like it’s time to look around and see what else we can do to make things better.
Here is a simple Ruby script:
# frozen_string_literal: true
require 'json'
require 'time'
require 'httparty'
module RubyVersion
class Response
attr_reader :code
attr_reader :json
def initialize(code:, json:)
@code = code
@json = json
end
def success? = (200..299).include?(code)
end
API_URL = 'https://api.github.com/repos/ruby/ruby/releases/latest'
def self.fetch_response
http = HTTParty.get(API_URL, headers: { 'User-Agent' => 'static-typing-demo' })
Response.new(code: http.code.to_i, json: JSON.parse(http.body))
end
def self.fetch(printer)
resp = fetch_response
raise "HTTP #{resp.code}" unless resp.success?
data = resp.json
published_at = Time.parse((data['published_at'] || Time.now.utc.iso8601).to_s)
printer&.call((data['tag_name'] || data['name']).to_s, data['html_url'], published_at)
end
end
PRINTER = proc { |tag, url, published_at|
puts "Fetched tag=#{tag} published_at=#{published_at.utc.iso8601} (url=#{url})"
nil
}
puts RubyVersion.fetch(PRINTER) if $PROGRAM_NAME == __FILE__
Before we move on, let’s check what this code does. The script fetches information about the latest Ruby release via the .fetch_response method. The information is returned as an instance of the RubyVersion::Response class. The .fetch_response method is called by our main entry point .fetch, which accepts one mandatory parameter printer - a Proc defined in the constant PRINTER.
Just like we would do in real life, we’ll cover this code with the necessary tests. Here is a simple MiniTest file that covers all major aspects of our script.
# frozen_string_literal: true
require 'minitest/autorun'
require_relative '../app/fetch_ruby_latest_with_types'
class TestRubyVersionFetch < Minitest::Test
def test_fetch_response_structure
resp = RubyVersion.fetch_response
assert_kind_of RubyVersion::Response, resp
assert_kind_of Integer, resp.code
assert_kind_of Hash, resp.json
end
def test_fetch_with_printer_proc
received = {}
printer = proc do |tag, url, published_at|
received[:tag] = tag
received[:url] = url
received[:published_at] = published_at
nil
end
summary = RubyVersion.fetch(printer)
assert_nil summary
assert received[:tag]
assert received[:url]
assert_kind_of Time, received[:published_at]
end
def test_fetch_without_printer
summary = RubyVersion.fetch(nil)
assert_nil summary
end
end
Let’s check what we do here. With test_fetch_response_structure, we ensure that .fetch_response works correctly, doesn’t raise exceptions, and returns a non-empty response of the correct type. With test_fetch_with_printer_proc, we cover our main business logic of accepting the Proc, calling .fetch_response, and passing all the necessary data to it. Finally, with test_fetch_without_printer, we test what happens when we pass nil. Even though the printer parameter is defined as mandatory, without any guard statement, we can still pass any value — including nil.
Now let’s add a file with type definitions.
module RubyVersion
class Response
attr_reader code: Integer
attr_reader json: Hash[String, untyped]
def initialize: (code: Integer, json: Hash[String, untyped]) -> void
def success?: () -> bool
end
API_URL: ::String
def self.fetch_response: () -> Response
def self.fetch: (^(String, String, Time) -> nil) -> nil
end
PRINTER: ^(String, String, Time) -> nil
For simplicity, I didn’t provide detailed type definitions for the Hash we receive from GitHub’s endpoint. In real life, we might want to go deeper and cover that part with types as well.
The syntax of RBS is very similar to Ruby, so it’s not difficult to understand what it describes. You may notice that for our .fetch method, we specified what type of data it supports. This means we don’t just “allow” a printer parameter to be present (though nil is possible), but we describe exactly what kind of value we accept. The same applies to all other parameters and return values.
Let’s break the code a bit and pass nil to the .fetch method like this:
puts RubyVersion.fetch(nil) if $PROGRAM_NAME == __FILE__.
When we run steep check, it will immediately spot the issue:
> bundle exec steep check
# Type checking files:
.F
app/fetch_ruby_latest_with_types.rb:49:23: [error] Cannot pass a value of type `nil` as an argument of type `^(::String, ::String, ::Time) -> nil`
│ nil <: ^(::String, ::String, ::Time) -> nil
│
│ Diagnostic ID: Ruby::ArgumentTypeMismatch
│
└ puts RubyVersion.fetch(nil) if $PROGRAM_NAME == __FILE__
~~~
Detected 1 problem from 1 file
It tells us:
Cannot pass a value of type nil as an argument of type ^(::String, ::String, ::Time) -> nil
— which gives us enough information about the issue and how to fix it. Now, without even running our tests, we can ensure we’ll never pass invalid data.
That also means we no longer need this test:
def test_fetch_without_printer
summary = RubyVersion.fetch(nil)
assert_nil summary
end
Steep (a static type checker) simply won’t let us pass anything but a Proc of the right shape. We can go even further and simplify other tests.
# frozen_string_literal: true
require 'minitest/autorun'
require_relative '../app/fetch_ruby_latest_with_types'
class TestRubyVersionMinimal < Minitest::Test
def test_fetch_response_structure
resp = RubyVersion.fetch_response
refute_nil resp
end
def test_fetch_with_printer_proc
received = {}
printer = proc do |tag, url, published_at|
received[:tag] = tag
received[:url] = url
received[:published_at] = published_at
nil
end
summary = RubyVersion.fetch(printer)
assert_nil summary
assert received[:tag]
assert received[:url]
end
end
Now, for the remaining cases, we only test the logic, not the types or the shape of the data we deal with.
In other words, we split responsibilities between MiniTest and Steep: the first validates that the business logic works as expected, the latter ensures we always deal with what was designed.
Static typing in Ruby cannot and will never replace tests. Similar to how it works in strongly typed languages, it’s a tool that brings clarity and confidence to your code.
And just like you’d spend your time in, say, Java, working with RBS or Sorbet (whichever you prefer) is not an “extra” time that none of us has. It’s the same time you’d otherwise spend debugging your app manually or writing an excessive amount of tests. As we’ve seen many times before - using static typing pays off.