DEV Community: Rafał Piekara

API tests in the repository? It can be done with HttpClient!

Rafał Piekara — Wed, 09 Feb 2022 06:32:55 +0000

If you create JSON API, you probably know by heart the support for tools such as Postman, Insomnia, Curl. However, when querying with them, it is not possible to store API tests in a repository and manage them with version control. I also thought it was impossible until I found this video. JetBrains tools have a built-in ingenious plugin - HttpClient. In this post, I have prepared for you a short demonstration of its capabilities using Ruby Mine and Ruby on Rails. API tests in the repository? Can be! Very much!

As a demonstration environment I will use a simple application written in Ruby on Rails. It took me 7 minutes to create this simple API with simulated authorization! I was timing myself on purpose. That's why I love RoR! But to the point.

The application has a simple structure. The main actor is the user who can own books and cars. Collector. Let's say it's such a typical directory application. Simply put.

I created the data structure with the following migrations.

Model definition:

And controllers.

Routing:

And `ApplicationController`, into which I put practically all the logic.

In API we can:

Check if the application is running (home action).
Download all books of a given user from the database.
Download all cars of a given user from the database.
Download a list of all users in the database.
Log in to the application and obtain an authorization token

Access to specific user data is secured with a token that should be provided in the Authorization header.

Before starting, I created a few users, a few books and a few cars in the database.

We start our adventure with HttpClient. Just create a file with the .http extension and RubyMine will do the rest and adjust the interface to fire queries.

I have created the api_test.http file.

First requests. I check if the API works. One line is enough:

GET http://localhost:3000

And the result:

Okay, but it probably won't end with one request. Fortunately, I don't have to enter the address in subsequent queries every time, what's more, I can have addresses configured for different environments and run my client in one of them.

I add the http-client.env.json file in which I set the environment and the url variable.

{
  "development": {
    "url": "http://localhost:3000"
  }
}

And now I can use a variable instead of a patched url. The IDE tells me everything beautifully.

We separate subsequent queries with three hashes: ###

It's time to log in

I am adding a new request, this time of the POST type. See how easy it is to define headers and parameters.

Authorization was successful and I got an auth_token in response. Now it's time to capture it, assign it to a variable, and use it in subsequent queries. This is done in the code that we put in braces with the percentage {%%}, which is just JavaScript.

POST{{url}}/login
Accept: application/json
Content-Type: application/json

{
  "email": "user1@email.com",
  "password": "password"
}


> {%
  auth_token = response.body['auth_token']
  client.global.set("token", auth_token)
%}

###
GEThttp://{{url}}/users/1
Accept: application/json
Content-Type: application/json
Authorization: Bearer {{token}}

We can now authorize our inquiries with a token:

HttpClient also has something for test fans. You can write automated tests for your queries! These tests are run together with queries, and their results are visible in the IDE runner.

###
GEThttp://{{url}}/users/1
Accept: application/json
Content-Type: application/json
Authorization: Bearer {{token}}

> {%
 client.test("Get User",function() {
   client.assert(response.body['books_count'] === 5, "Books count returned is wrong")
 })

 client.test("Status",function() {
   client.assert(response.status === 200, "Response status is not 200")
 })
 %}

What now? Git commit, git push. And we have versioned tests of our API.

You can find the repository with the above code here.

RSpec - clear test documentation

Rafał Piekara — Fri, 04 Feb 2022 07:02:50 +0000

If you are a Ruby on Rails developer, testing is your bread, it's in your blood. Or maybe you haven't had to deal with the tests yet, because you are just starting the adventure with the DHH child. Anyway, I have a tip for you that will make your testing much more readable and convenient. And every time you use the RSpec password, you will think "readable test documentation".

For testing, I use the most popular library in the RoR world - RSpec. Additionally, my setup complements DatabaseCleaner, ShouldaMatchers, and FactoryBotRails.

group :test do
    gem 'rspec-rails',
    gem 'factory_bot_rails'
    gem 'shoulda-matchers'
    gem 'database_cleaner'
end

ENV["RAILS_ENV"] ||= "test"
require 'spec_helper'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'shoulda/matchers'

Dir[Rails.root.join("spec/support/**/*.rb)].each { |f| require f }

RSpec.configure do |config|
  config.fixture_path = "#{::Rails.root}/spec/fixtures"
  config.use_transactional_fixtures = true
  config.infer_spec_type_from_file_location!

  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.strategy = example.metadata[:js] ? :truncation : :transaction
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end
end

Shoulda::Matchers.configure do |config|
  config.integrate do |with|
    with.test_framework :rspec
    with.library :rails
  end
end

The code we will test looks like this:

class Fotballer < ApplicationRecord
    validates :name, presence: true, length: { maximum: 250 }
    validates :surname, presence: true, length: { maximum: 250 }
    validates :club, length: { maximum: 250 }
    validates :nationality, presence: true, length: { maximum: 30 }
end

require 'rails_helper'

RSpec.describe Footballer, type: :model do
    describe "database columns" do
        it { should have_db_column(:name).of_type(:string) }
        it { should have_db_column(:surname).of_type(:string) }
        it { should have_db_column(:club).of_type(:string) }
        it { should have_db_column(:nationality).of_type(:string)
    end
end

With the basic configuration of RSpec, placed in the spec_helper.rb file and performing tests, the console does not print too readable messages, and it is impossible to track the progress of individual tests. Let's just look at what we get.

What if we would like to monitor the test progress on an ongoing basis and check what has already been done and is green, and what has not passed? Just slightly change RSpec configuration in spec_helper.rb and set config.color to true and config.formatter to :documentation.

RSpec.configure do |config|
  config.color = true
  config.tty = true
  config.formatter = :documentation
end

The test result looks much better than before.

Personally, I attach great importance to how the test is printed on the console. In the event of an error, it's much easier to find out where the problem lies. Besides, by checking the entire system, I am able to estimate how many more corrections are waiting for me while the tests are running.

However, if you want to get off the console and editor and use the only valid RoR IDE at the moment, which is Ruby Mine, the tests are well served there. I prefer this tool to. One click is enough and the test progress is clear and understandable. It is important to choose something according to your own preferences.

Anyway, for me, the statement: RSpec - clear test documentation will always be the same.

Read about it in the RSpec documentation.

Wordpress in docker is slow ... I have a solution for that!

Rafał Piekara — Tue, 01 Feb 2022 09:32:46 +0000

Docker WordPress is slow, terribly slow. But I have a way.

See one simple trick! WordPress and Docker haters hate it!

In docker-compose.yml, in the place where we configure the volumes, we will add the flag :delegated.



    volumes:
      - my_wordpress_db:/var/lib/mysql:delegated

###
    volumes:
      - ./wp-content:/var/www/html/wp-content:delegated

These two sites in
docker-compose.yml
do the job. It is possible to work, even quite comfortably 💪🐳

Range and Date in Ruby on Rails

Rafał Piekara — Mon, 31 Jan 2022 06:50:11 +0000

Ruby on Rails has its own extension of the Date class, making it very comfortable to work with dates.

No parsing, no conversion, we write our date helpers like a natural language, so we can read the code in fluent English and at times forget that we are dealing with a programming language. Today I'll show you how to use the combination of the Range and Date classes in Ruby on Rails to create a readable date check.

The specificity of Ruby allows for one more great thing - expanding core classes. In this example, we will extend the Date class provided by Ruby on Rails.

Case:

In the offer of report modules or dashboards, you can meet operations consisting of comparing data, filtering data from the previous year, discussion or week. Working with dates in RoR is super fun anyway, but the snippet below will make it even more fun.

class Date

  def is_in? range
    range.include? self
  end

  class << self
    def today
      Date.current
    end

    def previous_year
      today.prev_year.beginning_of_year..today.prev_year.end_of_year
    end

    def current_year
      today.beginning_of_year..today.end_of_year
    end

    def previous_month
      today.prev_month.beginning_of_month..today.prev_month.end_of_month
    end

    def current_month
      today.beginning_of_month..today.end_of_month
    end

    def previous_week
      today.prev_week.beginning_of_week..today.prev_week.end_of_week
    end

    def current_week
      today.beginning_of_week..today.end_of_week
    end
  end

end

We extend the Date class here.

First, I declare an instance method that will check if the date is within the given range. This is an instance method, which will call for instance, or in simpler terms - directly on the date.

def is_in? range
  range.include? self
end

Then extend the Date class with static methods. I am overwriting today method.

def today
  Date.current
end

I create a previous_year method using a Range that returns a date range for the previous year.

def previous_year
  today.prev_year.beginning_of_year..today.prev_year.end_of_year
end

Next, I create a current_year method that returns a date range for the current year.

def current_year
    today.beginning_of_year..today.end_of_year
  end

Next, the previous_month, current_month, previous_week, and current_week methods.

def previous_month
  today.prev_month.beginning_of_month..today.prev_month.end_of_month
end

def current_month
  today.beginning_of_month..today.end_of_month
end

def previous_week
  today.prev_week.beginning_of_week..today.prev_week.end_of_week
end

def current_week
  today.beginning_of_week..today.end_of_week
end

After creating these auxiliary methods, we can easily write date checking conditions.

Date.today.is_in?(Date.current_week)

invoice.date.is_in?(Date.previous_year)

Date.current_week.include?(report.date)

Combining the Range and Date classes in Ruby on Rails is a good idea to improve the readability of your code.

In the documentation, you can read about the Range class and the Date class.

Spread Operator in Ruby and Ruby Ranges

Rafał Piekara — Sun, 30 Jan 2022 11:06:44 +0000

We all remember the revolutionary in JavaScript world turned out to be the introduction of spread operator with the ES6 standard. Working with the collection has become pleasant and easy. Joining arrays has become very simple. You might think that this makes JS unique in this regard… but no. We used the spread operator in Ruby before it became fashionable. So, if you want to know what the spread operator in Ruby and Ruby Ranges looks like (a very interesting object), I invite you to read it.

I've learned from experience that Ruby language has a well-developed API when it comes to operations on collections. All thanks to the Enumerable module and the Array class, which provide all interesting functionalities.

Concat

And so Ruby has a concat method that is used to join arrays together, so, to actions very often used in JS.



[1, 2].concat(['a', 'b']) #=> [1, 2, 'a', 'b']

Ruby Magic

Let me show you an example that proves how great a language Ruby is. We'll use a few less obvious array methods and another cool tool such as Ruby Ranges.

Fake password generator

Let's write a simple password generator that we can use to seed the database, mock test data, or generate a password for the user.

Business requirements:

the password may contain lowercase letters
password may contain uppercase letters
the password may contain numbers
the password may contain special characters: $, #, *
the password may contain a randomly generated Wookie word, we will use the Faker gem

Let’s do this!

The password may contain lowercase letters

You don't need to install anything, we will use the Range object which allows us to generate a set of characters or numbers from a specified range. Then we'll convert this object to an array using the to_a method.



lowercase_letters = ('a'..'z').to_a

#=>
["a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z"]

The password may contain uppercase letters

Here we will also use Range all we need to do is to change parameters to uppercase.



capital_letters = ('A'..'Z').to_a

#=>
["A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z"]

The password may contain numbers

And Range again.



numbers = (0..9).to_a

#=>
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

The password may contain special characters: $, #, *

A simple board is enough here



special_characters = ['$', '#', '*']

It's easy to make a typo and forget the apostrophe, let's use more fancy syntax.



special_characters = %w{ $ # * }

#=>
['$', '#', '*']

The password may contain a randomly generated Wookie word

Seems like the hardest part, right?



wookie_words = Faker::Movies::StarWars.wookiee_sentence.split

#=>
["Ru", "ooma", "nng", "roooarrgh", "roooarrgh!"]

I use the split method, which takes space as a default separator and breaks the generated sentence into an array of words understood by Chewbacci.

Password generation

Now we have the components, it's time to create a password. First, let's sort all the criteria into one array.



password_matrix = lowercase_letters
                      .concat(capital_letters)
                        .concat(numbers)
                        .concat(special_characters)
                        .concat(wookie_words)

Shuffle

Let's mix it up with the bang method.



password_matrix.shuffle!

Sample

Let's pick 20 random pieces and mix it up again.



password_matrix = password_matrix.sample(20).shuffle

Join

Now we have to connect and we have the password ready.



password_matrix.join

#=>
"r4gP#Tsga.0aBbKc$kabukkmCYhnn-rowr"

Spread Operator

All the code, with a small, refactor to simplify the steps, looks like this:



def fake_password
  lowercase_letters = ('a'..'z').to_a
  capital_letters = ('A'..'Z').to_a
  numbers = (0..9).to_a
  special_characters = %w{ $ # * }
  wookie_words = Faker::Movies::StarWars.wookiee_sentence.split

  password_matrix = lowercase_letters
                .concat(capital_letters)
                .concat(capital_letters)
                .concat(numbers)
                .concat(special_characters)
                .concat(wookie_words)
                .shuffle
                .sample(20)
                .shuffle
                .join
end

A lot of this code, and I promised you a spread operator. Well, to combine arrays into one, all you need is *.



password_matrix = [ *lowercase_letters, *capital_letters, *numbers, *special_characters, *wookie_words]

Final code looks like that:



def fake_password

  lowercase_letters = ('a'..'z').to_a

  capital_letters = ('A'..'Z').to_a

  numbers = (0..9).to_a

  special_characters = %w{ $ # * }

  wookie_words = Faker::Movies::StarWars.wookiee_sentence.split

password_matrix = [lowercase_letters, capital_letters, numbers, special_characters, *wookie_words]

password_matrix

    .shuffle

    .sample(20)

    .shuffle

    .join

end

It work a treat!

The curse of versatility

Rafał Piekara — Tue, 25 Jan 2022 07:23:13 +0000

Versatility is supposedly a desirable feature that can stand out in the labor market. A programmer who knows many technologies becomes a tasty morsel for recruiters not only because they can send him offers for various positions, but also because his experience may be very necessary in the project. I like to describe myself as a versatile programmer. I have prepared some insights drawn from my own experiences.

How to understand versatility?

I understand it not only as knowledge of different languages, frameworks, technologies. Versatility is also the ability to find yourself in various styles of project and team management. It certainly includes experience in various types of business. I consider myself versatile, not only because I know Ruby, React, ReactNative, Flutter, Amazon Web Services, but also because I have worked on corporate projects, software houses, product companies and ran my own business.

Thanks to its versatility:

You are more attractive on the job market

Often, the specificity of projects requires broader experience in various domains. Additionally, for example, in Ruby, Java and C # programmers find their way very well.

You will not die

It is easy to adapt, you will not get lost in the labor market, because there will always be a company that needs a commando, what the backend will do, the design will be implemented, and the server is able to configure. Needless to say, such a commando has a good chance of negotiating a slightly higher rate, right?

You are not closed to one solution to the problem

Having some experience and knowledge of different technologies, you can propose several solutions for the same problem and choose the most appropriate one.

You can eliminate rubbish

You know what works and what doesn't. You can catch the firing of the tank faster to kill the fly.

You never get bored

You can easily change projects, types of tasks. You easily find yourself in the new reality. You enjoy experimenting.

Okay, but it's not quite that easy, is it?

Being a comprehensive developer in your company:

you are stopgap

You do everything that someone else doesn't want to or can't do. You are a budget option to carry out a project, which may not be particularly crucial, but recruiting a dedicated person would take time and burn money, and you are still paid your salary for that time.

You are constantly learning new things

The speed of learning is a feature of versatile people. You learn very quickly. So what? Won't you learn a new thing? Even one you never wanted to touch? You will learn, because you are versatile and have a good understanding of the business and dependencies of this world. You will learn because you like the employer, because you want to do this project and do something else. And so you learn new things over and over again that, in most cases, you'll use it once in your life.

You can do what you don't like

Even the most versatile programmer has something that feels good, has his / her golden zone, favorite language, framework, piece of application, but also knows a lot more things that others do not like. It is very possible that you will meet the finale where you keep doing things that nobody likes. For example, you are a full stack with a frontend flair, but still get the smack from query optimization instead of new frontend animations.

they pay little

I said above that there is a good chance that such a versatile programmer can negotiate a higher salary rate, but ... But it may be that you will be doing a lot of things that others on the team can't or won't do, and your stake won't be much at all deviate from the others on this level. But how? But you are so versatile that you should earn more. Well, your company's payroll policy may think otherwise… Frustration is around the corner.

You are not a specialist

You know a lot of different things, but you never really had time to seriously go deep into one technology, into one issue, because you have to keep jumping all the time. There's a good rule of thumb: Know everything about something and something about everything. It's fun to know a lot, but don't forget to specialize.

Impostor syndrome

The cheat syndrome comes in very easily in such a situation. After all, you know a lot, but in fact you can be bent on any topic, because… well, you lack this specialization.

You will be the bottleneck

You handle a lot of different things in a project that no one else can do. At some point it starts to rain. You start to be a bottleneck, because nobody apart from you is able to push work forward. People are starting to ask each other. The questions start to get frustrating, and then it is very possible that ...

Burnout

Dissatisfaction with work in such a situation is the minimum that can await you. Jumping on topics, pressure to be the one, deadlines, questions, fatigue.

These are just dangers that you may encounter if you consider yourself a comprehensive developer and are viewed as such on the team. I'm not saying it will happen, but it's always a good idea to have warning lights on the back of your head.

A versatile developer. Experience in various business categories and team structures. Knowledge of many technologies from backend, through devops, fronted and mobile. This profile is perfectly tailored for a startup, especially in the initial phase, where the entire team consists of multitasking commandos trying to bring unique value to the market as soon as possible.

Fullstack developer - versatile programmer. We live in a time of technology fission. Maybe fewer and fewer such fullstacks will develop due to the strong separation of layers in backend and frontend applications? Or maybe not, as shown in the world of Javascript with Node and frontend frameworks, where Node teams in most cases do not have a hard division into frontend and backend developers.

Versatility is a blessing. Versatility is a curse.

The symbol in Ruby - Explanation

Rafał Piekara — Mon, 24 Jan 2022 10:06:45 +0000

Everybody knows how to use it, everybody knows where, but why and what is its basis? What is a symbol in Ruby - I explain to myself and everyone who used it unknowingly so far. A few years ago, when I moved from .Net and C # to the Ruby world, I initially had trouble understanding what the symbols really were about. In one of the interviews, I got a question about the difference between a Symbol and a String and couldn't explain it. After total freaking out, I decided to explore the topic and now I am sharing with you the knowledge that I gained once and for all.

What is a Symbol?

an immutable object that is the name of another object
unique for each name
not associated with a specific instance of a given name while the program is running
is a string that cannot be changed

Symbol vs String

In Ruby, everything is an object, symbols and strings are objects, and instances of the Symbol class and the String class.

The string is declared using double or single quotation marks.

"string" 'string'

The symbol is defined by a colon before the literal.

:symbol

Symbols can also contain quotation marks and apostrophes

:"symbol" :'symbol'

Remember that such an entry means Symbol, not String.

If we use the above notation, the symbol may contain spaces or other special characters. In traditional notation, underscore is used as the separator.

Symbols cannot be modified

Strings can be modified, symbols are not. Symbols do not have bang methods that change the object that calls them.

"string".upcase #=> "STRING"

:symbol.upcase #=> :SYMBOL

"string".upcase! #=> "STRING"

:symbol.upcase!
NoMethodError: undefined method 'upcase!' for :symbol:Symbol

str = "string"
str = str << " sample" #=> "string sample"

sym = :symbol
sym = sym << " sample" #=> NoMethodError: unfined method '<<' for :symbol:Symbol
sym = sym << :sampel #=> NoMethodError: unfined method '<<' for :symbol:Symbol

The role of symbols and strings

The symbol identifies something important, it is an object for unique identifiers.

The string is intended for storing words or pieces of text, it is a type dedicated for text data.

Symbols and strings can be converted to each other

"string".to_sym #=> :string

:symbol.to_s #=> "string"

Symbol and memory

The same string has a different object_id every time, while the same symbol invoked three times returns the same value.

This is a key feature, plump meat, sweet flesh, a whole lot of symbols in Ruby.

Each string, although having the same value, is a separate instance, has its own object_id and its own memory location. The symbol, on the other hand, is unique, created only once while the program is running. Every time a symbol with the same value is called, one and the same instance is called.

This has an impact on code performance. Each such string takes additional memory space.

Historical curiosity! As of Ruby 2.2.0, Garbage Collector deals with symbols. Previously, the performance issue between String and Symbol was tricky. Namely, the symbols were stored in memory for the entire duration of the program, which in the case of dynamic symbol generation, e.g. from responses from external services in the application running without restart, for a long time led to a memory leak. As of Ruby 2.2.0 there is no need to worry about memory with numerous symbols. In the case of strings, the situation remains unchanged.

To understand how Garbage Collector deals with symbols, you need to understand the difference between explicitly declared symbols and dynamically created symbols.

Explicitly Declared Symbols vs Dynamically Created Symbols

:symbol #=> deklaracja
"symbol".to_sym #=> dynamiczna kreacja

Garbage Collector only cleaned up dynamically created symbols.

Garbage Collector implementation in Ruby 2.2.0 and higher allows defending against the phenomenon called DoS symbol - denial of service attack symbol.

A Dos symbol is when the system dynamically creates a lot of symbols, eg by processing the Json response from an API. Memory is leaking.

Despite the improvement of the Garbage Collector mechanism, creating symbols from the received data will never be completely safe, e.g. when creating a method dynamically from parameters:

define_method(params[:method].to_sym) do
end

This symbol was dynamically created to trigger the method. When it is further used, after being destroyed by the Garbage Collector, it will no longer be possible to call this method.

The same String, used several times, will be instantiated and destroyed each time, and Symbol, because it occupies one, permanent place in memory, will use the same instance for the entire duration of the program. It is similar to the case of a symbol created dynamically until it is marked for destruction by the Garbage Collector.

The efficiency with equality operators

Memory issues become apparent when comparing Strings and Symbols. Since strings are variable and each string has an object_id, Ruby never really knows what the value of a particular String is, so it has to check character by character. When comparing two Strings, Ruby must check both sequences of characters to see if they have the same values and if they are arranged in the same order. Comparing object identifiers will produce a skewed result because two identical strings with the same value have different object_id.

Comparing the Symbols is completely different. The symbols do not change. Two symbols with the same value have the same object_id. Due to this immutability, Ruby is sure that the Symbol has not changed over the course of the program, so there is no need to compare character sequences. All you need is a quick comparison of object identifiers. The whole operation happens much faster than with strings.

Let the numbers speak for themselves…

require 'benchmark'

str = Benchmark.measure do
        1_000_000.times do
          "string"
        end
      end.total #=> 0.07

sym = Benchmark.measure do
          1_000_000.times do
          :symbol
          end
      end.total #=> 0.39999999999999994

string_comparison = Benchmark.measure do
                        1_000_000.times do
                            "string" == "string"
                        end
                    end.total #=> 0.13

symbol_comparison = Benchmark.measure do
                        1_000_000.times do
                            :symbol == :symbol
                        end
                    end.total #=> 0.4999999999999999

Storage of Symbols

There is one more performance aspect worth noting. All symbols are stored in memory in one collection.

We have access to it via:

Symbol.all_symbols

How does this impact the performance? Every time the same String is called, it is instantiated and destroyed after use.

When calling symbols, it looks like Ruby checks the global collection first, and if it finds the symbol there, returns it immediately. If it does not find it, then it creates a new instance, also placed in the symbol collection, and returns it faster the next time, because it will be available there. Symbols are efficient to compare, store, and use.

Symbol Simulation

Ruby gives you the ability to simulate the behaviour of a Symbol on a String by calling the freeze method. This makes string an invariant constant. However, this does not impact the memory. Two frozen strings are still two different instances. A frozen object, like a Symbol, cannot be modified. It is instantiated only once for each individual instance, then it is called for use.

Curiosity!

Symbol, fixnum, bignum, float are frozen by default. By using frozen strings as Hash keys, we can get better code performance than with symbols.

Where to use the Symbols?

There is no clear definition of when to use Strings and when to use Symbols.

The most common example of using symbols are Hash keys.
The allowed notation is:

old_hash = { :symbol_key => "some value" }

cool_hash = { symbol_key: "some value" }

The second example shows the currently adopted new notation.

Why is it better to use symbols as keys?

Because they present unique values that are not static, while strings are the default containers for data. Therefore, Symbol fits better as an identifier. As is the case with Hash keys. If we use a String as a key, Ruby will create a new instance each time it is invoked. In the case of symbols, one and the same object will be used.

If we have a hash declared with symbols as keys, we cannot access them with strings, the other way around is the same.

There is an object in Ruby on Rails that allows you to get to values using symbols and strings on a single Hash.

HashWithIndifferentAccess

The object is HashWithIndifferentAccess. Using symbols with this object is much faster than using a regular Hash.

hash = {} #=> {}
hash[:symbol] = 1 #=> 1
hash[:symbol] #=> 1
hash['symbol'] #=> nil

hash = HashWithIndifferentAccess.new #=> {}
hash[:symbol] = 1 #=> 1
hash[:symbol] #=> 1
hash['symbol'] #=> 1

Symbols are also keywords for method arguments

def method_name(name:, age:)
end

method(name: "John", age: 12)

Symbols are used to define attributes in classes

attr_accessor :name, :age

Symbols indicate an instance of classes or methods

When declaring a class, method or variable, Ruby automatically creates its name in the form of a Symbol, hence the following entries are possible:

my_array.send(:pop)
my_array.respond_to?(:map)

Interestingly, if we have a class called Controller, a method of controller, and a variable controller, and although in different contexts this name will refer to different values, this object will be called every time.

Symbols in enum in Ruby on Rails

There is an enum object in Ruby on Rails that uses symbols to define acceptable values for a particular field.

What is worth remembering?

I have encountered a case of confusing symbols with variables, which is a shameful mistake. The symbol is not a variable but a name or otherwise named object.

It is important to remember that Symbol is a special class in Ruby that is used to define permanent, unique names.

Variables, on the other hand, are names that refer to objects. At the moment when the object ceases to exist - the variable also ceases to exist.

Different with the Symbol. It exists even if the object it is named does not exist.

A symbol is not a variable - you cannot assign it a value.

Another interesting thing is that although the Symbol is not a String, it has a string representation which is a constant. If we have a Symbol written with quotation marks, then its string representation will also have spaces.

:"it is some symbol": "it is some symbol".to_s #=> "it is some symbol"

However, symbols with spaces are not commonly used and when there is no other possibility of writing, they are used as a last resort.

A few simple rules

Finally, a few more simple rules when using Strings and Symbols, if that was still a problem. Therefore, in addition to the examples above, please note that:

when we want to display something we should choose String
if we want to process the name somehow, use modifying methods on it, we know that we use String
when the name is meant to be a unique identifier, we use Symbol
when the same name is to be used multiple times, we use Symbol

Symbols are very noble objects in the Ruby world. Their skilful use gives only advantages, from code readability to performance and memory savings.

For more details, please refer to the Symbol class documentation

The protected modifier in Ruby

Rafał Piekara — Thu, 20 Jan 2022 22:59:34 +0000

Recruitment interviews, especially their technical part, usually follow a specific pattern. It is easy to anticipate the questions that may be asked. It is often the case that the developer who asks them is taken out of the project and busy with solving problems on a daily basis and does not have time to prepare some original and surprising questions (unless he is a sadist and likes to bully candidates, but who of us did not recruit and did not have a killer question up his sleeve?), so google for example "Ruby interview questions". The second possibility is that this developer is already on the nth interview, always asking the same questions out of pure routine. He may also ask what he himself was asked about when he was the candidate. I want to present to you and explain an issue that will appear in 90% of a job interview for a Ruby on Rails developer, and it is about the Protected modifier in Ruby.

What's the difference between Public, Private, and Protected, which are access modifiers?

Sounds familiar?

You may encounter these words in other languages. To understand their slightly different meaning in Ruby, let's take a look at how they function in Java, C # and PHP for comparison.

Java

Public - access to a method in a given package and in any other package

Private - access only within classes and not inheritable

Protected - This is almost identical to private, with one subtle difference, protected methods can be inherited

"C#"

Public - access to the method is unlimited from anywhere in the application

Private - methods available only within the class or structure in which they are defined

Protected - the method is available in the child class only if accessed through the child class

PHP

Public - the method is visible from the inside of the class, derived classes and outside the class

Private - methods available only from inside the class

Protected - the method is visible in all classes that inherit from the base class, including the base class

RUBY 💖💋💪

First, to be perfectly clear, these three words: public, private, protected, commonly referred to as access modifiers, are not really keywords, but ... methods.

Remember that in Ruby, the code which does something is called method, and is defined by the words def and end at the beginning and end of a given batch of code.

Public in Ruby

It is no different from any other language. In Ruby, all methods not explicitly specified by the other two modifiers are public, except for the class constructor, the initialize method, which is always private.

Public methods can be invoked by anyone, anywhere, and are therefore not subject to any restrictions. For the method to be public, no keyword is required, it is enough to declare it above the private and protected declarations.

Interesting fact!

Globally declared public methods outside of all classes are actually private methods of an instance of Object, Ruby's super extra mother class.

Private in Ruby

The recipient of a private method is always self.

They cannot be called for any instance of the class in which they are defined, because they operate only inside that class, which means that they can only be called in the context of a given object.

They can only be called in other instance methods of the same class and its subclasses. Private methods in Ruby are inherited.

When using private methods in the body of other methods, remember that we always do it in a function style, that is:

private_method ()

not

instance.private_method ()

self.private_method ()

It also follows that the private methods of another object cannot be accessed, even if that object is of the same class.

Protected in Ruby

Access to protected methods is restricted to the family only, but, compared to other languages, they can be invoked by objects of the same class but inside those objects.

They can always be called on behalf of any instance of a class or a subclass of it, so unlike private, they are not limited to only implicit calls on behalf of self.

Protected is used to operate on the internal state of other objects of the same class.

It is an access method that allows an instance of a given class to share the internal state, but at the same time prevents consumers of that class from accessing this state from the outside.

To quote Matz, the creator of Ruby:

,,A protected method defined in class C can be called on behalf of an O object by a method in P if classes O and P are subclasses of class C or are equal to it.”

Here are some examples to better understand the Protected modifier in Ruby.

We have the Employee class and two employees who symbolize its instances. Suppose a scenario where the boss wants to compare their salaries without exposing them to the outside world.

class Employee
  attr_reader :salary
  protected :salary

  def greater_salary_than(other_employee)
    @salary > other_employee.salary
  end
end

first_employee = Employee.new
second_employee = Employee.new
first_employee.grater_salary_than(second_employee)

class Person
  def older_than?(other_person)
    age > other_person.age
  end

  protected
  def age@age
  end
end

You can clearly see what I wrote about above. A protected method is not available outside the context of a given object, but is available inside the context of another object, if and only if the object is of the same type.

Additional information about Protected in Ruby and other modifiers

protected method can be called in the context of the given object as method () or self.method ()
Access modifiers can be declared in two ways:
all methods after the word private will be private unless we use protected somewhere along the way. Similarly, all methods after this declaration will be protected, unless we use the private modifier somewhere along the way
the second way is to first declare all the methods and then establish their access by listing their names in conjunction with the appropriate access modifier

# I way
private
def method

protected
def method 

# II way
def method
end

protected :method

calling respond_to? for a protected method it will return false. For clarification, respond_to? is a method that returns true if the object implements the method given as an argument. By default, it does not include private methods. They can be considered by passing the second argument to this method as true
let's go back to private methods for a moment. Although I wrote that we do not have access to them, there is one exception here. A trick known only to those who don't speak Rabi. Namely, you can get to them by calling the private method with the send method or by evaluating the block in the context of the object using the instance_eval method

p = Page.new
p.send :some_private_method
p.instance_eval(some_private_method)

This is a topic for another lecture, treat it as a Swiss curiosity, don't try it at home.

BTW, there is also a public_send method which works like send, except that private methods are omitted. It's easy to get confused.

Definition Spec in Ruby - implementation in RSpec

Rafał Piekara — Mon, 17 Jan 2022 05:34:24 +0000

Imagine this situation. Ruby on Rails project. You are working with your team on a mega-important business feature. You did three days. Everything flashes great. You give it back. Goes into production. Management opens Prosecco, Marketing starts ad words. Complete success 🎉🎉🎉🔥💪.

Meanwhile, an hour after the key release, a colleague from the other team deploys a feature he has been working on for 3 weeks. The feature might have waited another day if it had waited so long. Well, it's going to be in production, because QA was busy testing my key feature, and it's not a business change, some dashboard views and queries, nothing can be spoiled. It will fly straight into production. Pipelines turn green, but ... the application is lying, Puma does not get up. Fuckup. Clients call, support in panic, Prosecco is gasping.

It turns out that by some miracle a code entered the production, in which in one of the classes, at the very end, a small, stray, almost imperceptible letter "s" appeared. Probably a colleague was saving the file, he missed a finger and the letter was written. Nobody noticed during the code review, there was no time to enter the QA, tested in local, but the application crashed.

Sounds weird? Well, no, it's a case study from a project my friend is working on. A real, authentic fact that really happened.

Wait, but how everything worked locally, how pipelines went through since there was a character in the code that should never be there.

Three issues are to blame for this incident:

specificity of interpreted languages
specificity of Ruby on Rails
lack of adequate, minimum test coverage in the project

The specificity of interpreted languages

The difference between interpreted languages and compiled languages is that in interpreted languages, the code is executed on the fly, there is no build phase to allow the compiler to check that the project is at all building. Hence, any typos, syntax errors, and undeclared methods will only come to light when the dirty code fragment is executed. Nobody will warn us sooner.

The specificity of Ruby on Rails

RoR has a lazy loading mechanism in development and test modes. This means that it only loads the classes that are needed to execute the given batch of code. Only in production mode, the entire application code is loaded. As a result, unless there is a bug in the key RoR files responsible for initializing the application, Puma will always stand up in the development environment, and the tests, as long as they do not touch contaminated code, will always pass. The application will not get up on production. Puma won't get up if there is a syntax error in the code, or if a method that is not declared is executing.

No minimum test coverage

It just so happened that the flawed class in this example did not have any tests written.

The other tests did not touch this class, so it gave the impression that nothing was broken and that there is backward compatibility. Tests passed locally, passed in pipelines, and yet it was faulty.

Apparently, every programmer and every programmer worked on at least one project, in which they heard one of three variations: "We do not write tests because"

"... the client does not pay for writing tests"
"... there's no time, deadlines are chasing."
"... it's a simple feature, what to test here."

Who has never had such a fuckup, be the first to throw a stone.

One of my favourite thoughts at work is "Know how is important but the most important is to know how not."

Well, now both me and my friend and his bandmates, and you know "how not". It is time to formulate a short Know How.

If you don't write tests because there is some super important business reason (yes, super important one), it's always worth writing one test that saves your butt in cases like the one above.

I call it the definition spec.

describe MailingService do
  it 'is defined' do
    expect(described_class).not_to be nil
  end
end

It consists in the fact that the first test that I write when creating a new class is checking whether such a class is defined at all, which forces it to be loaded in test mode. These are 4 lines, and they really allow you to ensure a minimum of security and avoid typos. The definition spec in Ruby seems to be a tool tailored to this problem.

Look:

It's not much, but when he sees the green colour, I become calmer.

I created a module to avoid typing the same code every time. You can also use your own matcher. Here are some examples.

Own module:

# spec/support/test_helpers.rb
module TestHelpers
  def definition_spec
    expect(described_class).not_to be nil
  end
end

# w rails_helper.rb
RSpec.configure do |config|
  config.include TestHelpers
end

#Potem w teście
describe PaymentService
  it 'is defined' do
    definition_spec
  end
end

describe SomeClass do
  it 'is defined' do
    definition_spec
  end
end

Test result for red:

Test result for green:

Defining your own matcher

#spec/support/matchers.rb
require 'rspec/expectations'

RSpec::Matchers.define :be_defined do |expected|
  match do |actual|
    !actual.nil?
  end
end

# Potem w teście
describe PaymentService do
  it { is_expected.to be_defined }
end

describe SomeClass do
  it { is_expected.to be_defined }
end

Test result for red:

Test result for green:

In the case of TDD, I guarantee a dopamine incentive. You are writing a definition spec. it's red. You add the file and define the class. It’s Green. And you want to keep working 😃

If you want and have time for it, you can test if the public methods you want to use are defined. No mocking, no extensive scenarios. Minimal coverage that protects against trivial fuckups

Just as startups have the concept of MPV - Minimum Viable Product, I suggest you MVC, but understood as Minimally Verified Class. Something like this can help you introduce a Ruby definition spec into your routine.

Someone wise from the Ruby world (Andrzej Krzywda - you can find a broader context here) said that he works in Ruby because he likes to correct typos in production.

Let's not fix typos in production, let's do it earlier, much earlier.

When adding a definition spec, the tests crash if there is an unwanted letter in the class being tested.

Write definition spec in Ruby, seriously

Dunning-Kruger developer

Rafał Piekara — Fri, 14 Jan 2022 15:08:16 +0000

I suppose you are familiar with this feeling when, after completing one course or training, you have the impression that you have complete knowledge, expert knowledge. Be careful! You may have just been caught by Mr. Dunning and Mrs. Kruger. Simply put, the Dunning-Kruger effect is that when you know little you feel as if you know everything.

It is easy to fall under the illusion that 2 weeks may be enough to master a programming language well. Stuffing yourself with a large dose of knowledge puts you in a state of omnipotence. You have the feeling that there is no problem that cannot be solved, that you can compete in senior positions today.

Theory

A little theory about the Dunning-Kruger effect

Symptoms

Being in such a state becomes full of boldness and pride. It seems that there is no such recruitment question that you do not know the answer to. Unfortunately, this is only an illusion, so characteristic at the beginning of learning any thing. It is then easy for a total flop, an absolute failure, because there will always be someone at the recruitment interview who will be better than you. Who will crush you and drag you across the floor, so that you will be left for a long time to make any changes or apply for a new project.

This is how the Dunning-Kruger effect works. It throws us from the extreme to the extreme. The worst part about it is the lack of awareness of this state. Not understanding that you are only at the beginning of the road, that the more you know, the more you know, that you don't know, right?

That is why it is worth remembering at every step that there will always be someone who will crush us, be it in the company, during recruitment or even at a conference. Even if you have the feeling that your code is already awesome, it's "there is always a bigger fish".

How might the person with Dunning-Kruger affect colleagues? Absolutely destructive. Such a person breaks up the team. It's hard to work with someone who believes they have all the available knowledge. And if there is someone in the team who will not give up and will always try to demonstrate wrong thinking - a toxic atmosphere is guaranteed.

The path of self-reflection is priceless, remember that others can evaluate you. If you are blindly convinced of your own coolness, such an evaluation can be very painful. Nobody will take you seriously, because your shortcomings will be clearly visible on the palm of your hand.

Rewriting the course doesn't make you an expert. The only thing you can get out of it is a very narrow view of the problems or technology discussed by the author. I mentioned the limits of knowledge above. Let me explain this a little more. There is such a thing as the circle of knowledge and the limits of ignorance.

Imagine a small circle one centimeter in diameter. Can you calculate the circumference of this circle? You surely remember the pattern. And the field of the circle? Sure. So the area of the circle is the boundary of your knowledge, its length is the amount of knowledge that you currently believe you lack. You start learning, you do courses, bootcamps, training. Your circle of knowledge begins to grow, but with the circle, the circumference begins to increase with the circle. The boundaries of your ignorance are becoming more and more extensive.

As you learn new content, you start to see new areas for exploration. The more you know, the more you don't know.

What if I told you that there is no limit point, that this wheel can grow forever? Does it scare you? Frightens? And it shouldn't! The only feeling that should accompany you is humility, such simple, simple humility, humility in front of the fact that in a world filled with information, on the threshold of such a dynamically changing and developing IT industry, so many things remain to be known, while we still know little.

Are you a course addict?

The Dunning-Kurger Effect often affects course addicts. There is this development addiction phenomenon. We buy course after course, book after book, preferably from several different fields. Courses, such as courses, either give a very general overview of an issue and in fact, we only learn the basics, or they touch on a very narrow specialist section of the issue. In both scenarios, just completing the course, completing training, reading a book does not make us experts. And yet it is easy to get the feeling that after this specific course we can deal with any project, any problem that comes up before us. Expertise is determined by the experience, number and weight of solved problems, experienced crises and victories. An expert does not need to have a certificate and a litany of training sessions listed on their Linkedin profile. An expert must have poured liters of sweat, blood and tears behind him. Expertise is like a precious metal, it is forged under extreme conditions.

I have conducted trainings for people who want to change into programmers. In the middle of the course, which lasted 12 weeks, the students asked me questions about their financial requirements during recruitment interviews, because they would like to look for a job. 6 weeks after starting the programming course, completely from scratch. Then I was shocked! Today I understand it more!

I was shocked because I was entering the industry even before being a programmer became fashionable. There were no bootcamps and all these programming schools. There were no such developed frameworks. Programming wasn't as sexy as it is now. There was no React, Vue etc, it was revolutionary to use jQuery instead of Vanilla. My learning was difficult, access to the materials was more difficult. For this reason, it is easier today to see similar differences in perceiving knowledge and falling into a state of overconfidence and enthusiasm. I have nothing to do with this type of bootcamp or training, I would probably use it myself, if it was possible. However, when deciding on such training, you must have a certain mindset, certain assumptions that you will be bombarded with knowledge, if the course is actually as intense as promised in the advertisements and worth its considerable price, you will be overwhelmed by a mass of material that will not be able to effectively convert .

You will end the training with confidence, because you have covered a lot of issues during the course, but in fact none of them were remembered well enough.

The first interview is enough to get a verbal splash of cold water that will either sober up or nail down. May he sober up.

As we are already recruiting. You probably know from stories or anecdotes that sometimes stupid questions are asked during job interviews. I thought it was just a joke, that it couldn't be true, because what kind of company asks a programmer what kind of animal he feels or what he would take to a desert island. And not so long ago, when I changed my job, a very nice recruiter asked me what kind of fruit I am. Get it? What the fucking fruit I am. How important in this process was it that I replied "with a banana"? How important was it that this was the first fruit that came to my mind? These kinds of questions are of no use, and neither are theoretical questions of technology. Okay, they're important because we're able to get to know a candidate's body of knowledge, but that body of knowledge might as well have been learned, and mostly misunderstood. It doesn't really matter if you know the design patterns from theory. It is important if you know the problems that can be solved by applying them. Hence, I am a supporter of questions related to experience, challenges, successes, failures and problems. Perhaps it is worth the effort to inquire about the cache, performance, and understanding legacy problems you encounter. Questions presenting a real design problem are fantastic, for example:

"You have a task that must be delivered on Wednesday at 12:00. It's Tuesday 15:00. What will you do? You prefer to deliver what you can on Wednesday, but knowing that it will be incomplete, or will you give information to the client / team, that there is no chance that it will be on Wednesday and that you will miss the deadline, but you will deliver all the requirements? "

A classic problem, is it better to be on time and fail, or is it better to be late and deliver everything.

These types of questions will quickly expose the Dunning-Kruger delinquent, as it will turn out that superficial knowledge is not enough to make up for inexperience.

Let's summarize

The Dunning-Kruger effect, that's okay. I experienced it, probably your friends experienced it. If this has not happened to you yet, sooner or later you will feel this feeling of world domination, while what you have is not even suitable for ruling over a glass of water. Humility is such a grandiose word, and it can change so much. It is humility that will give you the opportunity to deal with the effect as soon as possible. Humility doesn't mean feeling like shit here, but it does mean knowing there's always something I may not know and it's easy to get hit for it. There can always be someone to put you out of the way and show you your place in the row.

Let Master Qui-Gon Jin remind you of all this:

There’s always a bigger fish

Simple Command

Rafał Piekara — Fri, 14 Jan 2022 14:44:45 +0000

Who ever worked in a rails project must have seen the so-called fat controllers, where the logic of individual actions is packed directly into controllers that automatically have hundreds of private methods and thousands of lines of code, and the actions look like this:

  def update
    @template.update_attributes(page_template_params)
    page_levels_ids = @template.page_levels.map(&:id)
    saved_levels_ids =  if params[:page_levels_ids]
                          params[:page_levels_ids].map{|id| id.to_i }
                        else
                          []
                        end
    ids_to_save = saved_levels_ids - page_levels_ids
    ids_to_remove = page_levels_ids - saved_levels_ids
    ids_to_remove.each { |id| PageLevel.find(id).update(page_template_id: nil) }
    ids_to_save.each { |id| PageLevel.find(id).update(page_template_id: @template.id) }

    @template.reload
    PageProcessor::TemplateService.update_template(@template)
    redirect_to edit_page_template_path(@template)
  end

I have such good practice that I transfer all logic from controllers to external domain classes of services, commands, use cases - whatever you call it. When testing such controllers, I only care about the shape of the responses that return individual actions and whether the appropriate website was called with the appropriate parameters. That's all.

To use such a solution, PORO (Plain Old Ruby Object) is enough, while I like to use a small, nice library called Simple Command, which extends our PORO with a few things that improve the convenience and testing of such classes.

Link to library

From the documentation of the gem, we can read that:

to use SimpleCommand in your class you should (here I have a bit of a problem with the proper translation of it into Polish), precede it with the SimpleCommand class

prepend SimpleCommand

If you want to know what prepend is all about, check here.

we will be able to call our class through the .call method defined in it
our class will have two attributes that indicate the success of the operation: success? and failure?
if the operation is successful, the value returned by the call method will be available under the result attribute
if the operation fails, the errors from this operation can be read from the errors attribute

Testing such a class is very simple. We really only test 3 cases:

if the call will be successful if the correct parameters are given
if we get an error when entering incorrect parameters
whether the command will return the expected result on a positive end of the operation

Of course, we can dive in and see if there are any operations on other classes inside the command, or if array errors contain information about specific errors, or if the command throws exceptions suitable for our test cases. However, these three points above are enough to feel comfortable with the implementation of the logic contained in the command.

Now let's move on to the specific case of user login to the API. The code that I prepared is the agnostic framework, it shows that SimpleCommand and the command pattern it supports can also be used outside of Ruby on Rails, in scripts, console applications, automations, etc.

Classic example according to rails way:

require_relative './auth_token'

class BadAuthController < ApplicationController

  def login
    if email.nil? || email.length.zero?
      render json: { error: 'Email not valid' }, status: 422
    end

    if user && user.authenticate(auth_params[:password])
      render json: { user: user, auth_token: AuthToken.encode({ user_id: user.id }) }, status: :ok
    elsif user.blank?
      render json: { error: 'User not found' }, status: 404
    elsif !user.authenticate(auth_params[:password])
      render json: { error: 'Invalid password' }, status: 401
    end
  end

  private

  def user
    @user ||= User.find_by(email: auth_params[:email])
  end

  def auth_params
    params.require(:auth).permit(:email, :password)
  end
end

The login method is quite long. There are some ifs, some complex conditions, some renders. What if we add, for example, 2 Factor Authentication to the application? This logic will have to be tied down somewhere between the ifs. Distributing this code to private methods won't quite work. What if another action uses the same method and in the meantime, we modify the method to meet the new requirements?

Let's move all the logic to the LoginUser command. For the purposes of the example, the User and AuthToken classes are plugs, we are not interested in their implementation.

require 'simple_command'
require_relative './user'
require_relative './auth_token'

class LoginUser
  prepend SimpleCommand

  class InvalidEmail < StandardError; end
  class InvalidPassword < StandardError; end
  class UserNotFound < StandardError; end

  def initialize(auth_params)@email = auth_params[:email]
    @password = auth_params[:password]
  end

  def call
    raise InvalidEmail unless email_valid?
    raise UserNotFound if user.nil?
    raise InvalidPassword if password.nil? || !user_authenticated?
    logged_user_payload
  rescue InvalidEmail
    errors.add 422, 'Invalid email given'
  rescue InvalidPassword
    errors.add 422, 'Invalid password'
  rescue UserNotFound
    errors.add 422, 'User not found'
  end

  private

  attr_reader :email, :password

  def logged_user_payload
    {
      user: user,
      auth_token: auth_token
    }
  end

  def user_authenticated?
    user.authenticate(password)
  end

  def user
    @user ||= User.find_by(email: email)
  end

  def email_valid?
    !email.nil? && email.length
  end

  def auth_token
    AuthToken.encode({ user_id: user.id })
  end
end

What do we have here? The command accepts the parameters needed to log in. As logic is enforced, it throws its own exceptions, catches those exceptions, and sets error codes and error responses accordingly. There are a few private methods dedicated to make the code clearer.

Now let's see a test of such a command:

require_relative '../lib/login_user'
require 'spec_helper'

describe LoginUser do
  it 'is defined' do
    expect(described_class).not_to be nil
  end

  describe 'logging' do
    let(:auth_params) {
      {
        email: 'email@example.com',
        password: 'password'
      }
    }

    subject { described_class.call(auth_params) }


    it 'succeeds' do
      expect(subject).to be_success
    end

    it 'logs in user' do
      expect(subject.result).to have_key :user
      expect(subject.result).to have_key :auth_token
    end

    context 'when no email given' do
      let(:auth_params) {
        {
          email: nil,
          password: 'password'
        }
      }

      it 'fails' do
        expect(subject).to be_failure
      end

      it 'raises error' do
        expect(subject.errors.size).to be > 0
        expect(subject.errors.first[1]).to eq 'Invalid email given'
      end
    end

    context 'when no password given' do
      let(:auth_params) {
        {
          email: 'email@example.com',
          password: nil
        }
      }

      it 'fails' do
        expect(subject).to be_failure
      end

      it 'raises error' do
        expect(subject.errors.size).to be > 0
        expect(subject.errors.first[1]).to eq 'Invalid password'
      end
    end

    context 'when user not found' do
      before do
        allow(User).to receive(:find_by).and_return(nil)
      end

      it 'fails' do
        expect(subject).to be_failure
      end

      it 'raises error' do
        expect(subject.errors.size).to be > 0
        expect(subject.errors.first[1]).to eq 'User not found'
      end
    end

    context 'when invalid password' do
      before do
        allow_any_instance_of(User).to receive(:authenticate).and_return(false)
      end

      it 'fails' do
        expect(subject).to be_failure
      end

      it 'raises error' do
        expect(subject.errors.size).to be > 0
        expect(subject.errors.first[1]).to eq 'Invalid password'
      end
    end
  end
end

The tests are very simple. We check the happy path first, then check how the command behaves in the event of invalid credentials. Only this and so much.

And this is how invoking the command in the controller and testing for the login action will look like:

require_relative './command_helpers'

class AuthController
include CommandHelpers

  def login
    login = LoginUser.call(auth_params)
    if login.success?
      return { data: login.result, status: 200 }
    else
      return { errors: login.errors, status: 422 }
    end
  end

  private

  def auth_params
    param.require(:auth).permit(:email, :password)
  end
end

And here is the test:

require 'spec_helper'
require_relative '../lib/auth_controller'
require_relative '../lib/login_user'

describe AuthController do
  it 'is defined' do
    expect(described_class).not_to be nil
  end

  let(:auth_params) {
    {
      email: 'email@example.com',
      password: 'password'
    }
  }

  subject { described_class.new(auth_params) }
  let(:login) { instance_double(LoginUser)}
  before do
    allow(LoginUser).to receive(:call).with(auth_params).and_return(login)
    allow(login).to receive(:success?).and_return(true)
    allow(login).to receive(:result).and_return(anything)
    subject.login
  end

  it 'logs user via command' do
    expect(LoginUser).to have_received(:call).with(auth_params).once
  end

  it 'checks for command status' do
    expect(login).to have_received(:success?).once
  end

  it 'gets command result' do
    expect(login).to have_received(:result).once
  end

  it 'returns command result' do
    expect(subject.login[:data]).to eq login.result
  end

  context 'when login failed' do
    before do
      allow(login).to receive(:success?).and_return(false)
      allow(login).to receive(:failure?).and_return(true)
      allow(login).to receive(:errors).and_return(anything)
      subject.login
    end

    it 'checks for failure' do
      expect(login).to have_received(:failure?).once
    end

    it 'checks for errors' do
      expect(login).to have_received(:errors).once
    end

    it 'returns command errors' do
      expect(subject.login[:errors]).to eq login.errors
    end
  end
end

Simple scenario. At the controller level, we only check the correct execution of the command with the appropriate parameters. And the responsibility for the logic test and its correctness is delegated to another layer.

Well, what now? The moment we have more of these actions that use commands, we will have a good idea. We can grasp it through auxiliary methods. For the sake of example, I have thrown them into the included CommandHelpers module. The command is caught by handle, and it is already responsible for handling its responses or errors properly. This handler is always more expandable and customizable. However, I present to you the minimum version of the implementation.

module CommandHelpers

  private

  def handle(command)
    command_result(command) do |result|
      render json: result
    end
  end

  def command_result(command)yield({ data: command.result }) if command.success?
    yield({ errors: command.errors }) if command.failure?
  end
end

Then something like this is enough in the controller:

def login_with_handler
  handle LoginUser.call(auth_params)
end

And that’s it. 😃

As a result, we have the encapsulation of logic in a pleasant class that additionally contains information about the success or interruption of the action as well as clean and transparent controllers.

Attention! In the SimpleCommand repository on Github, you may notice that there have been no new commits there for several years. The library appears to be unmaintained, so you may be concerned about using it. Do not worry. Just look at the gem code and see that the entire SimpleCommand is really pure PORO without any dependencies. Equally, instead of installing the gem, we can include this code in some helper class in a rails application.