excid3/betterminitest.com

Learn how to write better Minitest tests

👋 I'm a Ruby and Rails developer building things for the community.

💻 Here's a few of the projects I'm working on:

• GoRails - Screencasts for Ruby on Rails developers
• Jumpstart - A complete Ruby on Rails SaaS template
• Hatchbox - Hosting for Ruby and Rails apps
• RailsBytes - Reusable templates for adding features to Ruby on Rails apps
• Rails Hackathon - A weekend hackathon for Ruby on Rails developers to get together and build their ideas.
• Pay - A complete payments engine for Ruby on Rails apps
• Noticed - Notifications system for Ruby on Rails apps
• ActsAsTenant - Multitenancy for Ruby on Rails apps
• A bunch of other Ruby gems

✨ You can follow me on Twitter @excid3

If you like my work and want me to be able to keep improving it, please sponsor me on GitHub.

betterminitest.com's Issues

SUGGESTION: "Getting Started" Best Practices

IMHO, if this is BetterMinitest, we should include (probably several) "best practices" topics.

Since we are just starting out, I suggest a Start Strong (getting started best practices) set of recommendations, like:

1. Recommended environment configuration (Guard, Minitest Reporters, etc.)

• Minitest Reporters gem 'minitest-reporters'
• Guard: gem 'guard' and gem 'guard-minitest'
• Git configs for excluding whatever testing stuff we don't want to track
• OTHERS?? - I need expert advice here <<=======

2. Where to start? Avoiding the TDD or DDT debate, objective advice on how to get started writing tests which add the most value (but don't overwhelm) will be super valuable. Thoughts:

• Follow the "Learn Enough..." (Michael Hartl) convention of trivial controller & model tests to ease into the habit?
• Beyond that, best practices for maximizing the ROI of building tests
• EXPERT ADVICE NEEDED HERE

3. Example App - This may be just the way my brain works, but I have found that a real working app which evolves along with the material is a great way to make the concepts sink in.

4. Additional recommendations welcome.

Although pretty noobish in the Rails world, I have been in software development for 30+ years. My rusty hands-on skills prevent me from defining the best practices in this domain, but I am happy to do the grunt work to create the content (and the sample app) guided by Rails experts here.

[Example] Configuring test environment session_store

[Example] Test I18n strings

Assert I18n strings makes tests more reliable because it doesn't matter if the actual text changes, tests will still pass.

[Example] Testing against Subdomains

host! "#{@account.subdomain}.example.com"

[Example] Login with Devise

Show how to login in a user in your tests.

class ActionDispatch::IntegrationTest
  include Devise::Test::IntegrationHelpers
end

[Example] How to test subdomains in System tests

require "application_system_test_case"

class LoginTest < ApplicationSystemTestCase
  test "can login" do
    Capybara.app_host = 'http://subdomain.lvh.me'
    Capybara.always_include_port = true

    visit new_user_session_path

    fill_in 'user[email]', with: users(:one).email
    fill_in 'user[password]', with: 'password'

    find('input[name="commit"]').click

    assert_selector "p", text: I18n.t("devise.sessions.signed_in")
  end
end

[Example] Testing for multiple screen sizes

If we want to test for mobile sizes on top of testing for desktop, you can create another class that inherits from SystemTestCase and use in your test suite. In this example a file called mobile_system_test_case.rb is created in the /test directory with the following configuration.

require "test_helper"

class MobileSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :chrome, screen_size: [375, 667]
end

[idea] add a quick reference card

It would be nice to have a quick reference card with most used minitest commands and examples you can keep open while writing tests.

[Example] What is the role of a controller test in 2021?

I'm not entirely sure what the consensus would be around this topic. Personally, since controller tests are integration tests, I've been using them as an organizational mechanism for full-stack tests that don't exercise an entire path through the application. For example, I have some tests for conditional root routing and authorization in one of my controller test files.

That said, I don't know if that's how everyone is addressing controller tests these days, and I know that this change to Rails tried to pull controller tests further away from being functional tests (I think that's the right term). It begs the question, what role do controller tests play in the testing stack if they aren't meant to isolate behavior on the controller? In this article DHH kind of seems to assert that this kind of isolation isn't always totally necessary, but it still doesn't really answer what a controller test is supposed to be. Sure they're integration tests as he mentions, but we knew that from the inheritance of the test classes. The real question seems to be what separates them from integration tests?

[Example] Fixtures with Blind Indexes

one:
  email_ciphertext: <%= User.generate_email_ciphertext("[email protected]").inspect %>
  email_bidx: <%= User.generate_email_bidx("[email protected]").inspect %>
  first_name_ciphertext: <%= User.generate_first_name_ciphertext("John").inspect %>
  last_name_ciphertext: <%= User.generate_last_name_ciphertext("Doe").inspect %>
  encrypted_password: <%= Devise::Encryptor.digest(User, 'password') %>
  time_zone: "America/Chicago"
  
  # If using Devise::Confirmable
  confirmed_at: <%= Time.current %>

[System Example] Login with Devise (Warden) and Capybara