Forem: Moses Gathuku

Rails custom validation contexts

Moses Gathuku — Sun, 24 Apr 2022 19:53:30 +0000

In rails, it is possible to specify when the validation should happen. sometimes you may want to introduce new validation or skip some. Rails on option helps us achieve this.

class Post < ApplicationRecord
 validates :body, presence: true
 validates :title, uniqueness: true, on: :create 
 validates :published, exclusion: [nil], on: :update 
end

From the above validations:

it's not possible to create or update a post without a body
it will be possible to update a post with a duplicate title
it will be possible to create a record with published nil

Apart from the commonly used on: :create and on: :update rails allow us to provide custom contexts.

class Post < ApplicationRecord
 validates :title, presence: true 
 validates :published_at, presence: true, on: :publish
end

From the above example, we are validating published_at presence on: :publish. Custom contexts are triggered explicitly by passing the name of the context to valid? invalid? or save

post = Post.new(title: "Rails validations")
post.valid? # true 
post.valid?(context: :publish) # false 
post.save(context: :publish) # false

Testing External APIs with VCR in Rails

Moses Gathuku — Mon, 17 Feb 2020 18:33:46 +0000

Testing external APIs can be a time-consuming task, VCR is a ruby gem that allows you to record test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.

How VCR works?

When we make the first API call the request goes through full request and response cycle. VCR records the API request and response, which it saves as a cassette. In other words, VCR stubs it for future use. When the test is run again, no API call is made. Instead, VCR stubs the response. The test will run much faster as a result.

Installation

VCR works together with webmock a library for stubbing and setting expectations of HTTP requests. Add the latest version of VCR and Webmock in your Gemfile. Run bundle install to update dependencies.

gem 'vcr', '~> 5.0'
gem 'webmock', '~> 3.7', '>= 3.7.6'

Its good to add them in test group gems

Add them as development dependencies if you are developing a gem.

Configuration

VCR implements a configure block for different configuration. Add the below block in your test_helper.rb file.

VCR.configure do |config|
  config.allow_http_connections_when_no_cassette = false
  config.cassette_library_dir = File.expand_path('cassettes', __dir__)
  config.hook_into :webmock
  config.ignore_request { ENV['DISABLE_VCR'] }
  config.ignore_localhost = true
  config.default_cassette_options = {
    record: :new_episodes
  }
end

allow_http_connections_when_no_cassette - allows actual full request and response cycle, when no cassette found.
cassette_library_dir - directory where cassettes are stored.
hook_into - specifies a request stubbing library
ignore_request - default is false when true VCR makes full request without using cassettes even if they exists.
ignore-localhost - prevent VCR from having any affect on localhost requests
default_cassette_options - takes a hash that provides defaults for each cassette you use

Testing API calls

We are now ready to start testing APIs calls. For demo, purpose lets use JSONplaceholder a fake API for developers.

class VCRTest < Minitest::Test
  def test_fetch_post
    VCR.use_cassette("get_post") do
      response = Net::HTTP.get_response(URI('https://jsonplaceholder.typicode.com/posts/1'))
      assert_equal(200,response.status)
    end
  end
end

Run the test once and VRC will record in cassette_library_dir you defined in configure block, for our case cassettes/get_post.yml. When you run the test again no real connection is made making the process very fast. You may realize the speed when you have very many API endpoints to test.

Tips

If you are having issues with your cassettes or you need new data you can deletes the cassettes and a new version will be created.

If you have sensitive information in your responses like API keys. You can filter the keys in your configuration block.

VCR.configure do |config|
 config.filter_sensitive_data('<API_KEY>',ENV('API_KEY'))
end

If you like the blog, share with friends

Thanks for reading 🎉 😊

Testing Action Mailer in Rails

Moses Gathuku — Thu, 13 Feb 2020 17:24:42 +0000

Rails provide us with useful test helpers to ActionMailer which helps to easily iterate our design, test if our code queues the right email and our email contains the right content.

Getting Started

After creating a rails app we can generate a new Mailer in our app.

rails generate mailer NotificationMailer

With the above command we generate a mailer named NotificationMailer, this creates:-

A class NotificationMailer in app/mailers directory.
A class NotificationMailerTest in test/mailers/notification_mailer_test.rb
A preview class NotificationMailerPreview in test/mailer/preview/notificaton_mailer_preview.rb
A view directory notification_mailer in app/views

Mailer Logic

We are ready to create our first email. To create an email that is sent when users sign up in your application head to NotificationMailer in app/mailer

class NotificationMailer < ApplicationMailer
  default from: 'info@gathuku.tech'

  def welcome(user)
    @user = user
    mail(to: @user.email, subject: 'Welcome to my App')
  end
end

We have defined a welcome method that sends a welcome email. The method accepts the user object as the argument.

Note we have defined the default from at the top of our class.

Mailer view

After writing our logic remember notification_mailer directory that was created in our app/view, head into the directory and create a file named welcome.erb.html. The file will render HTML design for our email.

Note the naming convention. The name must match the name of our email method.

<!-- <!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">

  </head>
  <body>
    <h1>Thanks for signing,<%= @user.email %> </h1>
    <p>Welcome to the app</p>
  </body>
</html> -->

Mailer Preview

Remember the preview file that was created? Mailer preview enables us to preview our email design. This is helpful since we don't have to send the actual email to see our email design.
All we need is to define a method that implements our mailer. notification_mailer_preview.rb

class NotificationMailerPreview < ActionMailer::Preview
  def welcome
    user = User.first
    NotificationMailer.welcome(user)
  end
end

After this ensure your server is running and navigate to route http://localhost:3000/rails/mailers. All your mailers and specific email methods will be listed. Click welcome to view the welcome email design.

Testing

Your mailers class just like any other part of Rails application should be tested to ensure they are working properly.
Why should you test your mailers? below are some of the reasons.

To ensure that emails are being processed (created and sent).
To ensure that the email content is correct (subject, sender, body, etc).
To ensure the right emails are being sent at the right times.

There are two aspects of testing mailers.

Units tests
Functional tests

Units tests

In unit tests, we run the mailer in isolation with tightly controlled inputs and compare the output to a known value (a fixture.)
In our NotificationMailer we have welcome action which is used to send a welcome email when users sign up. Below is the unit test.

 # frozen_string_literal: true

require 'test_helper'

class NotificationMailerTest < ActionMailer::TestCase

  def setup
    @user = users(:one)
  end

  test 'welcome' do
    email = NotificationMailer.welcome(@user)
    assert_emails 1 do
      email.deliver_later
    end

    assert_equal email.to, [@user.email]
    assert_equal email.from, ['info@gathuku.tech']
    assert_equal email.subject, 'Welcome to my App'
    assert_match 'Thanks for signing', email.body.encoded
  end
end

In the test above, we create the email and store the returned object in the email variable. We then ensure that it was sent (the first assert), then, in the second batch of assertions, we ensure that the email does indeed contain what we expect.

Conclusion

To understand more about mailers. The line ActionMailer::Base.delivery_method = :test in config/environments/test.rb sets the delivery method to test mode so that email will not be delivered (useful to avoid spamming your users while testing) but instead, it will be appended to an array (ActionMailer::Base.deliveries)

You can clear the deliveries array with ActionMailer::Base.deliveries.clear