Cypress testing with Rails API Backend

Tomas Fernandez — Mon, 12 Aug 2019 01:09:26 +0000

At one of our current projects we started testing our key functionalities with Cypress for our React front-end. As we started writing our tests we stumbled upon a problem, how could we have a clear and easy way to setup and clear the data created/modified in the test in a secure way?

We couldn´t do it directly in our API as our front end is fed by several APIs. We also wanted our tests not to be written in Ruby so the cypress-on-rails gem wasn't an option.

Our main goal was to do this without having to add unwanted functionality to our Rails API.

Our first approach was to create a Rails controller that would only be enabled for Cypress testing. We chose to secure it via environment variables and an authentication token.

This option had one big pro: it was very easy to create and easy to maintain, it was only a very big controller in the middle of our production code.

Sadly, there were a number of drawbacks:

Code meant as test helper was in the middle of the production and business code.
We had to be really careful about the controller's security. Having a controller able to delete cascade several of our entities was a huge risk to have.

The last point was really important to us. A mistake in the APIs deployment could lead to someone wiping half of our database!.

That's why we looked into another option: using Rails engines.

The pros:

Active Record models from our main app can be referenced from the engine.
Endpoints used by Cypress won't be available in production.
The code of the endpoints won't even be available in the production bundle.

This really lowered the chances that a mistake in deployment configuration left the endpoints available.

The code

Lets create a new Rails project first:

$ rails new cypress_api --api

Inside our newly created API, lets create our Engine to declare our cypress-specific endpoints:

$ rails plugin new cypress --mountable

This will create a cypress folder at the root level with our new Rails engine and will also append the gem configuration in our main Gemfile.

Run bundle install and remove the TODOs from the engines gemspec to be able to start the app.

Now, lets create a new controller inside the main app to signal the API is active. Write this code into app/controllers/status_controller.rb:

class StatusController < ActionController::API

  def status
    render json: {"status": "OK"}
  end
end

Let's do the same inside the engine, but with a different message. Inside cypress/app/controllers/cypress/status_controller.rb:

module Cypress
  class StatusController < ActionController::API

    def status
      render json: {"status": "Cypress OK"}
    end
  end
end

Also, add the corresponding route config in config/routes.rb and cypress/config/routes.rb as well.

Last, we have to mount our engine's endpoints to our main app. The thing is, we can't do that statically as we don't want the endpoints to be available at all times. We have to do it dynamically.

To do this, we have to add this snippet to the Engines main class in cypress/lib/cypress/engine.rb:

  config.cypress_engine = ActiveSupport::OrderedOptions.new
  initializer 'cypress_engine.configuration' do |app|
    if app.config.cypress_engine[:mounted_path]
      app.routes.append do
        mount Cypress::Engine => app.config.cypress_engine[:mounted_path]
      end
    end
  end

So what does this snippet do? If the config.cypress_engine option is declared anywhere in our environment files or application file the engines endpoints will be appended to the main app with a prefix.

For now, let's declare that option in our development.rb file.

 config.cypress_engine.mounted_path = "/cypress"

We are now declaring that our Cypress Engine endpoints will be mounted into our main app with the cypress prefix.

Let's try it out! Start Rails in development mode and access "/status" and "cypress/status". We can see that both endpoints are available!.

Now, lets start the app in production mode. If we try to access "/cypress/status" we can see that 404 is returned.

Great! Now the Cypress endpoints are not available in the production environment but is still bundled into our app. To omit adding the endpoints to our app while in production we can limit the Gem to only be installed while in development.

  group :cypress do
    gem "cypress", path: "cypress"
  end

We can also add another level of security to our engine in case someone removes this config by mistake.

Add this snippet to cypress/lib/cypress/engine.rb below what we previously added:

  initializer "cypress_engine.cypress_only" do
    unless Rails.env.development?
      abort <<-END.strip_heredoc
        Cypress Engine is activated in the #{Rails.env} environment. This is
        usually a mistake. To ensure it's only activated in cypress
        mode, move it to the development group of your Gemfile:

            gem 'cypress', group: :development
      END
    end
  end

If the cypress engine is used in an environment other than development, Rails startup will be aborted.

You can find all the code in this repo:

tomsfernandez / Rails-Cypress-API-Example

Example code of a Cypress setup for Rails API with Engines for Dev.to blog post

View on GitHub

(In the repo a new environment called "cypress" exists to add another level of security but it isn't really necessary)

Download Docker Images without Docker Pull

Tomas Fernandez — Sun, 07 Jul 2019 16:09:41 +0000

Docker pull is the basic command for using Docker images. It works most of the time but sometimes it freezes in the middle of the download. Lots of people have raised issues about this with hacks that involve killing a process or restarting the docker-machine several times.

All these hacks aren't an issue with small image sizes like the alpine distribution or an nginx image but, what about the large images? Images that weight like 500 MB or 2 GB?

These hacks aren't useful because they involve downloading large layers over and over again.

A better workaround is to download the images manually and load them to the docker-machine. This is a much better solution as the manual download has much lower chances to fail than restarting the docker-machine hoping that docker pull starts working.

To download a docker image manually, there is a script called 'download-frozen-image-v2.sh' in the Moby project that lets us do that:

https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh

moby / moby

The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

The Moby Project

Moby is an open-source project created by Docker to enable and accelerate software containerization.

It provides a "Lego set" of toolkit components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts and professionals to experiment and exchange ideas Components include container build tools, a container registry, orchestration tools, a runtime and more, and these can be used as building blocks in conjunction with other tools and projects.

Principles

Moby is an open project guided by strong principles, aiming to be modular, flexible and without too strong an opinion on user experience. It is open to the community to help set its direction.

Modular: the project includes lots of components that have well-defined functions and APIs that work together.
Batteries included but swappable: Moby includes enough components to build fully featured container systems, but its modular architecture ensures that most of…

View on GitHub

This script only needs three things installed:

Curl
Jq
Go

To use the script we only need to specify the image to download and the location relative to the current:



$ ./download-frozen-image-v2.sh "example" hello-world:latest

In this example we are downloading the image "hello-world:latest" in the "example" directory.

Note: be sure to specify the version tag. If not specified, the script will return Not Found (404)

This will download several files into the "example" directory:

manifest.json
repositories file
json with details of the image
folder for each layer in the image

The only thing next to do is load it into the docker-machine. The script outputs the command necessary to do it:



$ tar -cC 'example' . | docker load
af0b15c8625b: Loading layer [==================================================>]     977B/977B
Loaded image: hello-world:latest

Congratulations! You have pulled a docker image without the docker pull command!

DEV Community: Tomas Fernandez