Tag: Minitest

Ruby MiniTest 🔬- Minimal replacement for test-unit

Minitest provides a complete suite of testing facilities supporting TDD, BDD, mocking, and benchmarking.

minitest/test is a small and incredibly fast unit testing framework. It provides a rich set of assertions to make your tests clean and readable.

minitest/spec is a functionally complete spec engine. It hooks onto minitest/test and seamlessly bridges test assertions over to spec expectations.

minitest/benchmark is an awesome way to assert the performance of your algorithms in a repeatable manner. Now you can assert that your newb co-worker doesn’t replace your linear algorithm with an exponential one!

minitest/mock by Steven Baker, is a beautifully tiny mock (and stub) object framework.

minitest/pride shows pride in testing and adds coloring to your test output

minitest/test_task – a full-featured and clean rake task generator.
– Minitest Github

♦️ Incredibly small and fast runner, but no bells and whistles.

Let’s take the given example in the doc, we’d like to test the following class:

class Meme
  def i_can_has_cheezburger?
    "OHAI!"
  end

  def will_it_blend?
    "YES!"
  end
end

🧪 Unit tests

Define your tests as methods beginning with test_.

require "minitest/autorun"

class TestMeme < Minitest::Test
  def setup
    @meme = Meme.new
  end

  def test_that_kitty_can_eat
    assert_equal "OHAI!", @meme.i_can_has_cheezburger?
  end

  def test_that_it_will_not_blend
    refute_match /^no/i, @meme.will_it_blend?
  end

  def test_that_will_be_skipped
    skip "test this later"
  end
end

setup ()

# File lib/minitest/test.rb, line 153
def setup; end

♦️ Runs before every test. Use this to set up before each test run.

The terms “unit test” and “spec” are often used in software testing, and while they can overlap, they have some key differences:

🧪 Unit Test vs 📋 Spec: Key Differences

🔬Unit Test

  • Purpose: Tests a single unit of code (typically a method, function, or class) in isolation
  • Scope: Very focused and narrow – tests one specific piece of functionality
  • Style: Usually follows a more traditional testing approach with setup, execution, and assertion
  • Framework examples: Minitest (like in your Ruby file), JUnit, pytest
  • Structure: Often uses test_ prefix or Test classes with assertion methods

📝 Spec (Specification)

  • Purpose: Describes the behavior and requirements of the system in a more readable, documentation-like format
  • Scope: Can cover unit-level, integration, or acceptance testing
  • Style: Uses natural language descriptions that read like specifications
  • Framework examples: RSpec, Jasmine, Mocha, Jest
  • Structure: Uses descriptive blocks like describe, it, should

⚖️ Key Differences

1. ✍️ Writing Style:

  • Unit Test: 
    def test_array_is_empty with assertions
  • Spec: 
    describe "when array is empty" do
    it "should return error message"

2. 👁️ Readability:

  • Unit Test: More code-focused, technical
  • Spec: More human-readable, business-focused

3. 🎯 Philosophy:

  • Unit Test: Test the implementation
  • Spec: Specify the behavior (BDD – Behavior Driven Development)

📊 Example Comparison

🏷️ Our current Minitest code:

def array_is_an_empty_array
  assert_equal 'Provide an array with length 2 or more', two_sum([], 9)
end

🎨 RSpec equivalent (spec style):

describe "two_sum" do
  context "when array is empty" do
    it "returns an error message" do
      expect(two_sum([], 9)).to eq('Provide an array with length 2 or more')
    end
  end
end

Both test the same functionality, but specs emphasize describing behavior in natural language, making them easier for non-technical stakeholders to understand. 🎉

🔬 Mini-test equivalent:

# frozen_string_literal: true

require 'minitest/spec'
require_relative 'two_sum'

describe "TwoSum" do
  describe "when array is empty" do
    it "returns an error message" do
      _(two_sum([], 9)).must_equal 'Provide an array with length 2 or more'
    end
  end
end

The underscore _() in Minitest spec style is a wrapper method that converts the value into an expectation object.

Here’s why it’s used:

🔍 Why the Underscore _()?
🎯 Purpose:

The _() method wraps your actual value and returns a special expectation object that has assertion methods like must_equal, must_be, etc.

⚙️ How it works:
# This:
_(two_sum([], 9)).must_equal 'Provide an array with length 2 or more'

# Is equivalent to:
# 1. two_sum([], 9) returns some value
# 2. _() wraps that value into an expectation object
# 3. .must_equal() is called on that expectation object
🔄 Alternative Syntaxes
1. 📝 Using expect() (more readable):
expect(two_sum([], 9)).must_equal 'Provide an array with length 2 or more'
2. 🔧 Using value() (explicit):
value(two_sum([], 9)).must_equal 'Provide an array with length 2 or more'
3. 🏷️ Traditional unit test style (no wrapper needed):
assert_equal 'Provide an array with length 2 or more', two_sum([], 9)
💡 Why underscore specifically?
  • Minimal syntax: _() is short and doesn’t clutter the code
  • Ruby convention: Underscore often indicates “throwaway” or “utility” variables
  • Non-conflicting: Unlikely to conflict with your method names
  • Chainable: Creates a fluent interface for assertions
🎨 Complete comparison:
# Spec style with underscore
_(result).must_equal expected

# Spec style with expect (more readable)
expect(result).must_equal expected

# Unit test style (no wrapper)
assert_equal expected, result

The expect() version is often preferred because it’s more self-documenting!

🎨 Alternative Spec Style with Expectation Syntax:

# frozen_string_literal: true

require 'minitest/spec'
require_relative 'two_sum'

describe "TwoSum" do
  describe "when array is empty" do
    it "returns an error message" do
      expect(two_sum([], 9)).must_equal 'Provide an array with length 2 or more'
    end
  end
end

⚖️ Key Differences in Minitest

🔧 Setup Required:
  • Unit Test: require 'minitest/test'
  • Spec: require 'minitest/spec'
✍️ Assertion Style:
  • Unit Test: assert_equal expected, actual
  • Spec: _(actual).must_equal expected or expect(actual).must_equal expected
🏗️ Structure:
  • Unit Test: Classes with test_ methods
  • Spec: describe blocks with it blocks
🎯 Readability:

Both styles work with Minitest, but the spec style reads more like natural language documentation, making it easier to understand the intended behavior! 

Excellent question! Let me clarify the relationship between TDD/BDD (methodologies) and RSpec/Minitest (testing frameworks):

Happy Testing!

Writing Effective Test Cases 🚧 for Your Ruby on Rails Model: A Guide

When it comes to building robust and maintainable applications, writing test cases is a crucial practice. In this guide, I will walk you through writing effective test cases for a Ruby on Rails model using a common model name, “Task.” The concepts discussed here are applicable to any model in your Rails application.

Why Write Test Cases?

Writing test cases is essential for several reasons:

  1. Bug Detection: Test cases help uncover and fix bugs before they impact users.
  2. Regression Prevention: Tests ensure that new code changes do not break existing functionality.
  3. Documentation: Well-written test cases serve as documentation for your codebase, making it easier for other developers to understand and modify the code.
  4. Refactoring Confidence: Tests provide the confidence to refactor code knowing that you won’t introduce defects.
  5. Collaboration: Tests facilitate collaboration within development teams by providing a common set of expectations.

Now, let’s dive into creating test cases for a Ruby on Rails model.

Model: Task

We will use a model called “Task” as an example. Tasks might represent items on a to-do list, items in a project management system, or any other entity that requires tracking and management.

Setting Up the Environment

Before writing test cases, ensure that your Ruby on Rails application is set up correctly with the testing framework of your choice. Rails typically uses MiniTest or RSpec for testing. For this guide, we’ll use MiniTest.

# Gemfile
group :test do
  gem 'minitest'
  # Other testing gems...
end

After updating your Gemfile, run bundle install to install the testing gems. Ensure your test database is set up and up-to-date by running bin/rails db:test:prepare.

Writing Test Cases

Model Validation

The first set of test cases should focus on validating the model’s attributes. For our Task model, we might want to ensure that the title is present and within an acceptable length range.

# test/models/task_test.rb

require 'test_helper'

class TaskTest < ActiveSupport::TestCase
  test "should not save task without title" do
    task = Task.new
    assert_not task.save, "Saved the task without a title"
  end

  test "should save task with valid title" do
    task = Task.new(title: "A valid task title")
    assert task.save, "Could not save the task with a valid title"
  end
end
Testing Associations

In Rails, models often have associations with other models. For example, a Task might belong to a User. You can write test cases to ensure these associations work correctly.

# test/models/task_test.rb

class TaskTest < ActiveSupport::TestCase
  # ...

  test "task should belong to a user" do
    user = User.create(name: "John")
    task = Task.new(title: "Task", user: user)
    assert_equal user, task.user, "Task does not belong to the correct user"
  end
end
Custom Model Methods

If your model contains custom methods, ensure they behave as expected. For example, if you have a method that returns the completion status of a task, test it.

# test/models/task_test.rb

class TaskTest < ActiveSupport::TestCase
  # ...

  test "task should return completion status" do
    task = Task.new(title: "Task", completed: false)
    assert_equal "Incomplete", task.completion_status
    task.completed = true
    assert_equal "Complete", task.completion_status
  end
end
Scopes

Scopes allow you to define common queries for your models. Write test cases to ensure scopes return the expected results.

# test/models/task_test.rb

class TaskTest < ActiveSupport::TestCase
  # ...

  test "completed scope should return completed tasks" do
    Task.create(title: "Completed Task", completed: true)
    Task.create(title: "Incomplete Task", completed: false)

    completed_tasks = Task.completed
    assert_equal 1, completed_tasks.length
    assert_equal "Completed Task", completed_tasks.first.title
  end
end

Running Tests

You can run your tests with the following command:

bin/rails test

This command will execute all the test cases you’ve written in your test files.

Conclusion

Writing test cases is an essential practice in building reliable and maintainable Ruby on Rails applications. In this guide, we’ve explored how to write effective test cases for a model using a common model name, “Task.” These principles can be applied to test any model in your Rails application.

By writing comprehensive test cases, you ensure that your application functions correctly, maintains quality over time, and makes collaboration within your development team more efficient.

Happy testing!