When it’s about writing tests for a Ruby project, I prefer minitest to anything else. It’s fast and doesn’t require to switch mental context to any domain-specific language (DSL). It’s just Ruby.

Because minitest allows to express tests using plain Ruby, Ruby is the only necessary tool to run those tests.

$ ruby -Ilib:test test/foo/test_foo_test.rb

That works fine for one file, but a bit tricky for multiple test files at once.

minitest comes with a Rake task to run all tests. However for small projects it might be to much to bring Rake just for that case.

So I wrote a script to run tests without anything but Ruby. It’s basically a wrapper around a test runner that comes with minitest.

env command allows to find a script’s interpreter when its location is a non-standard one. In scripts it’s recommended to use env in shebang lines to find the executable and run it.

#!/usr/bin/env ruby

puts "Hello, world."

On GNU/Linux if it’s necessary to run a script’s interpreter with options, env has to be used with -S to pass options in shebang lines.

Recently I had an interesting conversation with colleagues on the topic of writing tests for code. In particular, it was about tests for hotfixes that need to be deployed as soon as possible. In this post, I’ll leave the results of that conversation aside and focus on what it inspired me to think about. On the question “Why do I write tests for code?”

A week ago my friend Pablo and me released the very first episode of Code && Beyond. None of us had any experience in podcasting or ever worked with voice and audio. But we did that!