Testing grab bag and smashed brain

Rich Steinmetz -


Recent (positive) events have smashed my brain. As a result, some things need to be modified for the coming month — more on that, most probably next week.

Curious Coders Chronicles

The Chronicles have continued again. Last week we even had two episodes:

  1. API and OAuth Authentication on Rails with @BorjaGVO
  2. Market Yourself as a Developer Part 2

You can subscribe at anchor.fm/curious-coder with your favorite podcast app (if your favorite podcast app is Spotify or Apple Podcast) and get notified about the next episodes coming out. ✅

RailsConf Update

I've booked an AirBnb room for 21/04 - 27/04 near the Plaza (10 min walking distance). The host says it's a "very big apartment and really nice and in a very convenient place", and offers the full apartment, i. e. one more room, for 250$ (imo pretty cheap from what I've seen). So if someone wants to immerse themselves into a coder's living community for a couple of days, send me a message! 😆

Testing grab bag

I repeated a couple of things a couple of times this week around testing, which ended up turning into a grab bag of thoughts. Enjoy.

  • Construct test names to describe expected behavior. I start the test name and a verb with the method that I'm testing in model tests, for example:
# For testing instance methods:
test "#execute sets customer's primary card number per default" do
  # ... some arrangements, an action, and some asserts ...
end

# Or for class methods:
test ".cls_method redirects the user to a beautiful place" do
  # ...
end

I got this # and . pattern from my RSpec days, and I still like to use it, but I often skip it in system and integration tests where I have user-centric test names instead, like:

test "admin sees a setup integration card after connecting to Stripe" do
 # ... lots of visits, finds, and 
end
  • Avoid record.reload where not necessary.
  • You can debug Rails system tests with headful Chrome (i.e., your application_system_test_helper.rb will have :chrome as the driver instead of :headless_chrome. Execution will stop at your breakpoint, and you can contemplate your gorgeous browser results.
  • Use Strong Migrations for potentially dangerous operations, like removing columns, to avoid deploy and prod failures. Write tests for the newly introduced behavior.
  • VCR builds upon webmock's intercepting of HTTP calls and writes the actual requests and responses to a structured YML file for the first time, then reads from the saved files, not making the requests. This gives you maximal trust in your tests, but adoption can be problematic if the team is unfamiliar with the tool or not testing-driven in general. Also, working with VCR can be hacky at times.
  • attr_accessor generates a getter() and a setter=() for the class that needs to be tested directly with a unit test or indirectly through other tests.
  • Use the inverses of assert_somethings instead of negating or nil-checking of the target objects. So basically, assert_nil or assert_not_nil instead of assert !obj.result.

Chapeau! 🎉