DEV Community: Vasily Polovnyov

RSpec & Rails: what not to write in `it`

Vasily Polovnyov — Thu, 19 May 2022 05:50:12 +0000

1. Useless, general words that bring no value:

# bad: what value? for what?
it "adds certain value"

# good
it "snoozes for an extra 5 minutes"


# bad: which result is correct?
it "returns correct result"

# good
it "returns user's initials"


# bad: how exactly it fails?
it "fails"

# good
it "raises a not found error"


# bad: formatted how?
it "returns formatted string"

# good
it "returns time in 24-hour format"

# bad: what 'ok' means?
it "is ok"

# good
it "creates draft invoices"

2. Implementation details:

# bad
it "changes @scheduled_on"

# good
it "reschedules campaign"


# bad
it "sets @todos"

# good
it "assigns todos to a given user"

3. Lies:

it "returns time in 24-hour format" do
  expect(...).to eq "9:25"
end

it "strips leading zeroes" do
  expect(foo(" 9:25 ")).to eq "9:25"
end

RSpec & Rails: how to stub env vars

Vasily Polovnyov — Tue, 17 May 2022 09:02:25 +0000

In order to stub an environment variable in the test (which is probably missing in test environment), stub :[] or fetch method:

# If code relies on ENV["CHARGES_TOKEN"]
allow(ENV)
  .to receive(:[])
  .with("CHARGES_TOKEN")
  .and_return("XXX")

# If code relies on ENV.fetch("CHARGES_TOKEN")
allow(ENV)
  .to receive(:fetch)
  .with("CHARGES_TOKEN")
  .and_return("XXX")

If you want shorter syntax, take a look at ClimateControl gem:

ClimateControl.modify CHARGES_TOKEN: "XXX" do
  # ...
end

How to test code that works with an external API: a stub on Sinatra

Vasily Polovnyov — Sat, 14 May 2022 10:15:32 +0000

Imagine a situation: your application relies on an external service responsible for card charges. The service has a tiny API: get the card number (mask) by user ID, charge X dollars from the user. How do we test the code that works with this API?

Of course, you can actually request that external service in the tests. Maybe it even has a sandbox for such cases. But this solution is not so efficient. First of all, it slows down the tests: every request has a time cost. Secondly, it makes tests flaky: network issues will cause them to randomly fail. Thirdly, it's not always possible: the external service may have no sandbox or have strict request limits.

In such cases, it is better to use stubs for external services. I use four options of stubs, depending on the external service: is it my own or someone else's, stable or frequently changing?

One of the options is a fake service on Sinatra. Such as this one:

let(:fake_api) do
  Class.new Sinatra::Base do
    get "/users/:user_id/card" do
      content_type :json

      { number: "4111...1111" }.to_json
    end
  end
end

before do
  stub_request(:any, /api.nanocashier.com/).to_rack(fake_api)
end

There are two interesting things in the above code. Firstly, Class.new with the Sinatra::Base parent in let, so you don't add a global constant from the test. Secondly, the stub_request of Webmock, which routes all requests to the rack application.

I use such rack-based stubs when I have to mock an external service which doesn't have its own stubs (e.g. stripe-ruby-mock) and making adapter-like stub is not possible.

Quick tip: stub requests to unix sockets

Vasily Polovnyov — Thu, 12 May 2022 06:05:26 +0000

Sometimes, an application communicates with an external service not via Internet sockets, but via unix sockets:

Excon.get("unix:///ping", socket: "/tmp/unicorn.sock")

To stub requests like this in tests, use Webmock:

stub_request(:get, "http://unix/ping").to_return(status: 200)

Using Faker is anti-pattern

Vasily Polovnyov — Thu, 05 May 2022 05:36:10 +0000

In my opinion, Faker and randomly generated data is usually an anti-pattern in tests.

First of all, with Faker tests become nondeterministic: run - crashed, run again - passed. Such flaky tests are extremely difficult to debug and annoying on CI.

Secondly, random data slows down tests. Especially in factories: I worked on a project where switching from Faker to sequence { ... } accelerated the test suite by 12%.

Thirdly, Faker overuse leads to code duplication in the tests. For example, take a look at the test method that returns user's initials:

it "returns initials"
  user = described_class.new(name: Faker::Name.name)
  expected = user.name
    .upcase
    .split(" ")
    .map { |part| part[0] }
    .join("")

  expect(user.initials).to eq(expected)
end

This is an incomprehensible and confusing test: if the #initials method changes, the changes will have to be duplicated in the test as well. A better way would be to write it like this:

it "returns initials"
  user = described_class.new(name: "Daniel Craig Jones")

  expect(user.initials).to eq("DCJ")
end

I suggest you to take a closer look at Faker in your test suite: are you sure you need it?

Fake data in tests

Vasily Polovnyov — Tue, 03 May 2022 14:55:31 +0000

Tests are not only a tool to automatically check the code and its correctness, but also an excellent documentation. Every time I don't understand something in the documentation of a library, I look at the specs and quickly find an answer to my question.

In tests it is the best to use data as close to real-life as possible: "User" → "Ivan Pavlov", "ip" → "82.100.200.3", empty file → jpeg with your cat. This way we get good documentation and good examples of how to use our API.

To make the tests consistent, I prefer to use a single domain for the test data. For example, I often use:

1. Characters and quotes from The Simpsons:

user = User.new(name: "Bart Simpson", email: "bart@simpson.dev")

expect(user.to).to eq "Bart Simpson <bart@simpson.dev>"

2. Characters and quotes from '90s action movies:

comment: "Dead or alive... you're coming with me"

3. Lyrics of Eminem's or Beyoncé's songs (please don't ask):

do_request(text: "In my shoes, just to see what it's like to be me")

P. S. Some of you might mention Faker. I don't use it as I think it's an anti-pattern. I'll elaborate on this in next post.

Linting Ruby right in Neovim

Vasily Polovnyov — Thu, 28 Apr 2022 07:18:04 +0000

For Vim to lint the current file in the background and show errors directly in the editor, you need to do these three steps:

1. Install ALE (async code checker with Language Server Protocol support).

2. Setup it:

" What do we use for linting
let g:ale_linters = {
\ 'javascript': ['eslint'],
\ 'ruby': ['rubocop']
\}

let g:ale_linters_explicit = 1

" Lint Ruby files with binstub
let g:ale_ruby_rubocop_executable = 'bin/rubocop'

" Tune linter's error and warning signs
let g:ale_sign_error = '\u2022'
let g:ale_sign_warning = '\u2022'

" Let's leave a column for the signs so that the left side of the window doesn't move
let g:ale_sign_column_always = 1

3. You're beatiful!

“What” and “For what” in pull requests

Vasily Polovnyov — Mon, 25 Apr 2022 09:38:59 +0000

A few months ago, I came up with a template for pull requests consisting of two questions: "What?" and "For what?". You open a pull request, answer the questions, and send it to the reviewer. The reviewer dives right into the problem, understands faster what we are trying to accomplish, and visualizes a possible solution.

A couple of examples:

## What?
Update Rails to 6.1.3.2.

## For what?
To fix a security vulnerability: CVE-123123.


## What?
Before tracking a coupon, make sure it actually exists in the database.

## For what?
To avoid writing junk data like `utm_campaign`, `utm_source` or `utm_medium` into the analytics.

I've also noticed a positive effect for the pull request author: if you can't articulate "For what?", you don't actually understand the task; if the "What?" has "Also..." and "And...", it's better to split the pull request into several ones.

What are your thoughts on this topic? What kind of pull request templates do you use?

(All in all, I really recommend trying this!)

Rack application as a stub

Vasily Polovnyov — Mon, 03 May 2021 05:29:00 +0000

Sometimes you need to put a stub on a particular route, but do not want to make a controller for this. In this case use Rack application as a stub:

# config/routes.rb
get "wp-login", to: -> (env) { [200, {}, [""]] }

Learning Through Overuse

Vasily Polovnyov — Sun, 25 Apr 2021 21:00:50 +0000

Sometimes it's hard to know how often and in what situations it's best to use any particular technology. How many integration tests do I need? When can I not write them, when can I do without them? When is it better to use vanilla JS and CSS, and when to get into all that post- and preprocessor stuff?

In these cases, it helps me to bring the situation to the point of overuse. I don't know how many integration tests I need? For the next two weeks, I write only integration tests. In all cases, no matter what the internet says. Period. I don't know when enough vanilla JS and CSS will suffice? I'm building a page only with bare JS and CSS.

This approach gives quick feedback in the form of pain in places where the technology definitely doesn't fit. Oops, integration tests slow down and prevent quick refactoring of the module - I'd rather have unit tests here. Oops, with vanilla JS it's painful to keep track of form state - I'd rather have something reactive and product-ready.

My new favourite programming font: iA Writer Mono S

Vasily Polovnyov — Mon, 19 Apr 2021 07:17:20 +0000

My new favourite programming font is iA Writer Mono S:
https://github.com/iaolo/iA-Fonts/tree/master/iA%20Writer%20Mono

P. S. Also check out how they announced this and other fonts:
https://ia.net/writer/blog/a-typographic-christmas

Is it time to quit?

Vasily Polovnyov — Mon, 12 Apr 2021 05:44:08 +0000

The worst thing a programmer can do for his career is to trade ten years of his life not for ten years of experience, but for one year repeated ten times. You're sitting in your own cubicle, programming there, and then you stop and think: 'Wow! It is amazing how crazy I really am: ten years in the same place with the same Drupal'.

In order to spot such a problem in time, every six months I ask myself three questions:

What interesting, significant and important things have I done in the last six months?
What skills have I gained or improved over the past six months? Do I need them at all?
How am I doing with the team and company? What about the trust, values, and mission of the company? Do I still believe in them? Or is everything already filled with cynicism and pessimism?

If the answers to two of the three questions are discouraging, it's time to quit.