Padrino is a lightweight web framework for Ruby based on Sinatra. Padrino aims to provide a full-stack web framework with a modular and agnostic design. It is designed to be easy to use, flexible, and powerful, and it is built with the same principles as Sinatra, but with additional features and functionality.
Some of the key features of Padrino include support for multiple ORM/ODM libraries, routing, controllers, and views, as well as support for plugins, generators, and various helpers. It also provides a robust command-line interface for generating and managing applications and has built-in support for testing, security, and internationalization.
Web applications developed using Padrino can be tested using different tools since Padrino can easily integrate with different frameworks. However, in this post, we will look at the most widely used tools for testing Padrino, including those that are mentioned as defaults by the framework.
According to the testing pyramid, your application should incorporate tests for each code unit, such as methods, functions, and classes. These tests primarily focus on whether the method's output is correct, given a specific set of parameters or conditions. Unit tests are intended to be granular and lightweight, with all dependencies being mocked. It's important to write tests that account for both positive and negative outcomes when creating these tests. Now, let's explore some of the available options for performing unit testing.
Using generators to create basic tests
In Padrino, generators are a set of command line tools that automate the creation of various parts of a Padrino application. They are similar to Rails generators in providing a convenient way to scaffold a new Padrino application and generate controllers, models, views, and other components. Generators in Padrino are implemented using the Thor gem, which is a toolkit for building command-line interfaces.
When you create a new Padrino application using the Padrino command line tool, you can specify which generators to use by passing the --app option. The reason for mentioning this here is that you can also tell Padrino to create basic tests for your components using the generators. You can mention different flags in the command to do this. Thus, you can create tests for controllers, models, mailers, helpers, and migrations using generators. Note that this approach only creates basic skeletal test cases under the test directory. To ensure that you have a robust testing suite, use other libraries and tools that aid in testing, like those mentioned below, to create a more comprehensive suite.
Testing using Minitest
Minitest is a lightweight testing framework for Ruby that is designed to be fast, easy to use, and extensible. It provides a simple API for writing and running tests, and it can be used to write a wide range of tests, including unit, integration, and acceptance tests. Minitest provides a simple API for writing unit tests, including methods like assert, assert_equal, assert_in_delta, and many others. One of the strengths of Minitest is its flexibility. It is designed to be easy to extend, so you can customize it to meet your specific testing needs.
require "minitest/test" class TestSample < Minitest::Test def setup @sample = Sample.new end def test_are_you_an_employee assert_equal("Yes", @sample.are_you_an_employee?) end def test_is_it_your_birthday refute_match(/^no/i, @sample.is_it_your_birthday?) end def test_that_will_be_skipped skip("test this later") end end
You can also use Minitest::Spec, which is a behavior-driven development (BDD) style of testing. It allows you to write tests that describe the behavior of your application. In this style, you define tests using the "describe", "it", and "assert" keywords. This style is useful when writing more descriptive and expressive tests. Minitest Spec is a more explicit syntax that provides an alternative way of writing tests. Both Minitest Test and Minitest Spec can be used for testing, and the choice between them largely depends on personal preference and the project's needs.
require "minitest/autorun" describe Sample do before do @sample = Sample.new end describe "when asked employment status" do it "must respond positively" do _(@sample.are_you_an_employee?).must_equal "Yes" end end describe "when asked about birthday" do it "won't say no" do _(@sample.is_it_your_birthday?).wont_match /^no/i end end end
Testing using Shoulda
Shoulda provides a collection of RSpec-style matchers and macros for testing common Padrino functionality. It simplifies the process of writing tests by allowing developers to use a more expressive syntax that can be easily read and understood. It also provides some useful helper methods to write concise, easy-to-read tests for models, controllers, and views. Shoulda is a meta gem and uses behaviors of Shoulda Context and Shoulda Matchers.
require_relative '../test_config' require 'shoulda/matchers' class UserTest < MiniTest::Test context "associations" do should have_many(:posts) end context "validations" do should validate_presence_of(:email) should allow_value("[email protected]").for(:email) should_not allow_value("not-an-email").for(:email) end context "#name" do should "consist of first and last name" do user = User.new(first_name: "John", last_name: "Smith") assert_equal "John Smith", user.name end end end
Testing using Test::Unit
Test::Unit is a testing framework that is included with Ruby. It provides a simple and lightweight way to write and run unit tests in Ruby. Test::Unit was originally based on the xUnit testing framework family, which includes frameworks like JUnit (for Java) and NUnit (for .NET).
Test::Unit allows you to define test cases by creating classes that inherit from Test::Unit::TestCase. You can then define test methods inside these classes, using a naming convention of test_something (where "something" is a description of what you're testing). Test::Unit provides a number of assertion methods that you can use to test your code. These include methods like assert, assert_equal, assert_in_delta, and many others. You can also use setup and teardown methods to set up and clean up any test data that you need.
require 'test/unit' class TestArray < Test::Unit::TestCase def test_array_can_be_created_with_no_arguments assert_instance_of Array, Array.new end def test_array_of_specific_length_can_be_created assert_equal 20, Array.new(20).size end end
Testing using Bacon
Bacon is a small and lightweight clone of RSpec for Ruby that is often used in combination with Padrino. Tests are defined using the should method, which describes what the test is checking, and a block containing the code to be tested.
require 'bacon' describe 'A new array' do before do @ary = Array.new end it 'should be empty' do @ary.should.be.empty @ary.should.not.include 1 end
Testing using Rack::Test
Padrino supports Rack::Test, a testing library that provides a simple API for making HTTP requests to your application and testing the responses. Rack::Test is built on top of Rack, the underlying web server interface used by Padrino, making it an excellent choice for testing Padrino applications.
Testing using RSpec
RSpec is a popular testing framework for Ruby that provides a domain-specific language (DSL) for writing tests. To use RSpec with Padrino, you will need to add the rspec and rspec-core gems to your Gemfile, and run bundle install to install them. Once you have the gems installed, you can create a spec directory in the root of your Padrino application, and create spec files for your models, controllers, and other application components. The padrino-rspec gem provides support for Padrino-specific features such as controllers, routes, and views in RSpec tests.
An application comprises different modules working together. Ensuring that they do so in harmony is achieved using integration testing. This type of testing focuses on areas where integrations are done between different modules, databases, file systems, network systems, APIs, helpers, and UI components. These tests utilize some degree of mocking, although not entirely. If you are going to check the integration of an API and the database, then you do not need to mock these two; but instead you can mock other aspects of the code like user inputs and business logic.
Tools for integration testing
You can write integration tests using the same tools used for unit testing, like MiniTest, Bacon, Test::Unit, Rack::Test, RSpec, and Shoulda, mixing them up as per your requirement. Minitest can be used with other testing tools and frameworks like Rack::Test to create integration tests. Minitest also provides a MiniTest::Mock class and a MiniTest::Stub module that can be used to mock and stub objects and methods in your tests.
Capybara for integration testing
describe "the signup process" do before :each do User.make(:email => '[email protected]', :password => 'caplin') end it "signs me in" do visit '/sessions/new' within("#session") do fill_in 'Login', :with => '[email protected]' fill_in 'Password', :with => 'password' end click_link 'Sign in' page.should have_content 'Success' end End
End-to-end testing forms the top of the testing pyramid. Through this form of testing, we focus on user scenarios, that is, whether the system is working as per the user's expectations and is able to satisfy those business needs. These tests comprise UI-level interactions that exercise other components internally, like APIs, helpers, databases, and network systems.
Testing using Capybara
Capybara is a Ruby library that helps you simulate how a user interacts with your web application. It can be used to write acceptance tests for web applications by automating the process of simulating user actions such as clicking buttons, filling in forms, and following links. Capybara supports several popular web testing frameworks, such as Selenium and RackTest. Another gem called capybara-padrino provides integration testing support for Padrino applications using the Capybara framework.
Testing using Cucumber and Selenium
Cucumber is a popular choice for implementing BDD (Behavior Driven Development). The focus remains on automating test scenarios in understandable syntax, called Gherkin. When using Cucumber, you need to create a feature file with the Gherkin scenarios and then corresponding step definition files containing the code that will tell the system what needs to happen when encountering a particular step in a scenario.
In the below example, we will use Cucumber to outline our test case and Selenium to interact with the browser. We are interacting with a simple ToDo app to archive all the todos.
The feature file will look like this:
Feature: Job posting
- As an employer
- I want to post a job
- So that potential candidates can apply
Scenario: Posting a job
- Given I am on the home page
- When I click the "Post a Job" link
- And I fill in the job details
- And I click the "Submit" button
- Then I should see the job listed on the jobs page
require 'selenium-webdriver' Given(/^I am on the home page$/) do @driver = Selenium::WebDriver.for :firefox @driver.navigate.to "http://localhost:3000/" end When(/^I click the "(.*?)" link$/) do |link_text| element = @driver.find_element(:link_text, link_text) element.click end When(/^I fill in the job details$/) do @driver.find_element(:id, "job_title").send_keys "Software Engineer" @driver.find_element(:id, "job_description").send_keys "We are looking for a software engineer with experience in Ruby on Rails." @driver.find_element(:id, "job_location").send_keys "San Francisco, CA" end When(/^I click the "Submit" button$/) do @driver.find_element(:name, "commit").click end Then(/^I should see the job listed on the jobs page$/) do element = @driver.find_element(:xpath, "//td[contains(text(), 'Software Engineer')]") expect(element).not_to be_nil @driver.quit end
testRigor for End-to-End Testing
Utilizing the tools mentioned above for end-to-end testing can produce favorable outcomes, but they may not be as user-friendly as they appear. For BDD to be effective in development, multiple teams should be able to collaborate and contribute to the creation of test cases. While Cucumber does facilitate this to a significant degree, there remains a reliance on developers or automation engineers to comprehend or modify the actual step definitions, as they are coded. Additionally, a scalable, remotely accessible tool is advantageous for expanding business operations.
Fortunately, testRigor offers a no-code, cloud-based solution for end-to-end testing. Although many BDD tools purport to allow test writing using the Gherkin language, it can be inflexible and challenging to articulate complex test scenarios. In contrast, testRigor employs a more straightforward syntax based on plain English. testRigor also includes visual, audio, email, and SMS testing features, as well as support for loops and reusable rules. These rules are also defined in plain English, eliminating the need for coding.
Being a cloud-based application, testRigor enables easy automation setup without the hassle of installing and configuring software, which is common with other automation tools. It supports cross-platform testing across web, mobile, and desktop platforms, covering a broad range of devices. In a nutshell, testRigor is a one-stop system for end-to-end UI automation.
login //This is a reusable rule with the username and password saved compare screen to stored value “Home Dashboard” check that table does not contain “Software engineer” click “Post a Job” to the left of “My Profile” check page contains “Job Posting” enter “Software Engineer” in “job title” enter stored value “Software engineer JD” in “job description” enter “San Francisco, CA” in “job location” click “Save” select “Jobs Dashboard” from “More” click on "view responses" within the context of table "Jobs Dashboard" at row containing "Software Engineer" and column "Actions"
You can see that it is quite easy to refer to table data and compare screenshots with testRigor. This is just the tip of the iceberg though. You can check out more features over here.
This post mentions tools that are mostly used to test Padrino applications and will help you create a solid testing pyramid. Choosing a testing tool majorly depends on your requirements for the tool. This in fact is also applicable to your choice of a development tool. It is always better to keep those in mind before committing to any framework or tool.