Model tests in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this Rails model test?

Given the following RSpec test for a Rails model, what will be the test result?

Ruby on Rails

RSpec.describe User, type: :model do
  it "is invalid without an email" do
    user = User.new(email: nil)
    expect(user).not_to be_valid
  end
end

A The test raises a NoMethodError due to missing 'be_valid' matcher.

B The test fails because the User model does not validate email presence.

C The test passes because the User model requires an email.

D The test is skipped because no subject is defined.

💡 Hint

Check if the User model has a validation for email presence.

The test expects the user to be invalid without an email. If the User model validates presence of email, the test passes.

❓ state_output

intermediate

What is the value of errors after validation fails?

Consider this Rails model test snippet. What will be the content of user.errors[:email] after validation?

Ruby on Rails

user = User.new(email: nil)
user.valid?
user.errors[:email]

A [] (empty array)

B ["can't be blank"]

C ["is invalid"]

D nil

💡 Hint

What error message does Rails add for missing required fields?

When a presence validation fails, Rails adds "can't be blank" to the errors for that attribute.

📝 Syntax

advanced

Which option correctly tests uniqueness validation in Rails model?

You want to test that the User model validates uniqueness of email. Which RSpec test code is correct?

A it { should validate_uniqueness_of(:email) }

B it { should validate_uniqueness_of_email }

C it { expect(User).to validate_uniqueness_of(:email) }

D it { should validate_uniqueness(:email) }

💡 Hint

Check the syntax of the shoulda-matchers gem for uniqueness validation.

The correct syntax uses 'validate_uniqueness_of' matcher with should.

🔧 Debug

advanced

Why does this model test raise an error?

This test raises an error when run. What is the cause?

Ruby on Rails

RSpec.describe User, type: :model do
  it "validates presence of email" do
    user = User.new
    expect(user.valid?).to be_falsey
  end
end

A The test raises an error because the User model lacks any validations.

B The test raises an error because 'valid?' returns nil instead of boolean.

C The test raises an error because 'be_falsey' is not a valid matcher.

D The test does not raise an error; it runs and fails or passes depending on validations.

💡 Hint

Check if 'be_falsey' is a valid RSpec matcher and what 'valid?' returns.

'be_falsey' is a valid matcher and 'valid?' returns true or false. The test runs without error.

🧠 Conceptual

expert

What is the purpose of 'subject' in Rails model tests?

In RSpec model tests, what does defining 'subject { described_class.new }' achieve?

A It defines the default object for test examples, simplifying test code.

B It automatically runs validations before each test example.

C It sets the database schema for the model during tests.

D It mocks the model to avoid database calls during tests.

💡 Hint

Think about how 'subject' is used in RSpec to refer to the main object under test.

'subject' defines the main object tested, so you can write cleaner tests without repeating code.

Practice

1. What is the main purpose of model tests in a Rails application?

easy

A. To check data validations and model methods work correctly

B. To test the user interface layout

C. To verify database server performance

D. To check network connectivity

Solution

1. Step 1: Understand what model tests cover

   Model tests focus on the data layer, ensuring validations and methods behave as expected.

2. Step 2: Differentiate from other test types

   User interface and network tests are handled by other test types, not model tests.

3. Final Answer:

   To check data validations and model methods work correctly -> Option A

4. Quick Check:

   Model tests = data rules and logic [OK]

Hint: Model tests check data rules and methods only [OK]

Common Mistakes:

• Confusing model tests with UI tests
• Thinking model tests check server or network
• Assuming model tests check database performance

2. Which of the following is the correct syntax to test a presence validation on a Rails model attribute name using RSpec?

easy

A. expect(user).to validate_presence(:name)

B. expect(user).to be_validates_presence_of(:name)

C. expect(user).to have_presence_validation(:name)

D. expect(user).to validate_presence_of(:name)

Solution

1. Step 1: Recall RSpec validation matcher syntax

   The correct matcher is validate_presence_of(:attribute) used with expect(model).

2. Step 2: Check each option for exact syntax

   Only expect(user).to validate_presence_of(:name) matches the correct RSpec syntax for presence validation.

3. Final Answer:

   expect(user).to validate_presence_of(:name) -> Option D

4. Quick Check:

   RSpec presence validation = validate_presence_of [OK]

Hint: Use validate_presence_of matcher exactly in RSpec [OK]

Common Mistakes:

• Using incorrect matcher names
• Adding extra words like 'be_' or 'have_'
• Missing the '_of' suffix in matcher

3. Given this model test snippet:

RSpec.describe User, type: :model do
  it 'is invalid without email' do
    user = User.new(email: nil)
    expect(user).not_to be_valid
  end
end

What will this test check?

medium

A. That a User with an email is invalid

B. That the User model has a method called email

C. That a User without an email is invalid

D. That the User model saves successfully without email

Solution

1. Step 1: Analyze the test setup

   The test creates a User with email: nil, meaning no email is given.

2. Step 2: Understand the expectation

   The test expects user to NOT be valid, so it checks that missing email makes the user invalid.

3. Final Answer:

   That a User without an email is invalid -> Option C

4. Quick Check:

   Missing email -> invalid user [OK]

Hint: Check what attribute is nil and expected validity [OK]

Common Mistakes:

• Misreading the test as checking presence of method
• Thinking it tests saving instead of validation
• Confusing valid and invalid expectations

4. You wrote this model test:

it 'validates presence of title' do
  post = Post.new(title: '')
  expect(post).to be_valid
end

Why does this test fail?

medium

A. Because title is empty but test expects valid

B. Because Post.new requires a title argument

C. Because be_valid is not a valid matcher

D. Because the test is missing a database save

Solution

1. Step 1: Understand the test setup

   The test creates a Post with an empty string for title.

2. Step 2: Check the expectation vs validation

   If the model validates presence of title, empty string is invalid, but test expects valid, causing failure.

3. Final Answer:

   Because title is empty but test expects valid -> Option A

4. Quick Check:

   Empty title ≠ valid if presence validated [OK]

Hint: Empty string fails presence validation, expect invalid [OK]

Common Mistakes:

• Assuming empty string counts as present
• Thinking be_valid matcher is wrong
• Ignoring validation rules in test

5. You want to test a custom method full_name in your User model that combines first_name and last_name. Which is the best way to write this model test?

hard

A. Write a controller test that calls full_name

B. Create a User with first and last names, then expect user.full_name to equal their combination

C. Check that full_name is validated for presence

D. Test that full_name is a database column

Solution

1. Step 1: Identify what to test for a custom method

   Custom methods should be tested by calling them and checking their return values.

2. Step 2: Choose the test that verifies method output

   Creating a User with names and expecting full_name to return combined string is correct.

3. Final Answer:

   Create a User with first and last names, then expect user.full_name to equal their combination -> Option B

4. Quick Check:

   Test method output by calling it with sample data [OK]

Hint: Test method output by calling it on sample model instance [OK]

Common Mistakes:

• Testing method as if it were a database column
• Confusing validation tests with method tests
• Writing controller tests instead of model tests