Ситуация: нужно убедиться, что мы списываем с пользователя правильную сумму, когда он воспользовался скидкой. Важный момент: у класса, отвечающего за это, увесистый АПИ с обязательными аргументами. Делаем первый подход:

context "when coupon is applied" do
  it "charges user $500" do
    allow(Cashier).to receive(:charge)

    purchase.perform

    expect(Cashier).to have_received(:charge)
      .with(
        user: user,
        sum: 500,
        description: "Покупка абонемента",
        coupon: coupon
      )
  end
end

Если оставить тест как есть, он будет отвлекать деталями совершенно не важными для проверки: пользователь, описание списания, купон. Раз мы хотим убедиться, что изменилась сумма, то и проверять нужно только сумму:

context "when coupon is applied" do
  it "charges user $500" do
    allow(Cashier).to receive(:charge)

    purchase.perform

    expect(Cashier).to have_received(:charge)
      .with(hash_including(sum: 500))
  end
end

Чем меньше пулреквест, тем лучше: легко отревьюить, легко задеплоить, легко искать ошибки. Чем больше пулреквест, тем сильнее дизмораль: увидел +700 -60 в Гитхабе и приуныл.

Кроме того, маленькие пулреквесты дают параллелить задачу: собрали письмо-заглашку, показали дизайнерам, пока дизайнеры смотрят — делаем отправку этого письма. Один пулреквест — одна атомарная задача.

Конечно, бывают сложные ситуации. Например, апгрейд Рельс. Одна огромная задача с кучей изменений. Но даже тут можно обойтись крошечными пулреквестами:

1. Открываем ветку rails-6-upgrade.

2. Делаем маленькие пулреквесты не к master, а к rails-6-upgrade.

3. Ревьюим, мержим их в rails-6-upgrade.

4. Когда апгрейд готов, мержим rails-6-upgrade в master.

Худшее, что может сделать программист для своей карьеры — обменять десять лет своей жизни не на десять лет опыта, а на один год, повторенный десять раз. Вот сидишь ты в собственном кубикле, программируешь там, тут остановился и подумал: Ух, ты! Ну и псих же я: десять лет на одном месте с тем же самым Друпалом. Бывает такое?

Чтобы вовремя заметить такое болото, раз в полгода я задаю себе три вопроса:
1. Что интересного, значительного и важного я сделал за прошедшие полгода?

2. Что за навыки я получил или прокачал за прошедшие полгода? Они вообще мне нужны?

3. Как мне команда и компания? Что с доверием, ценностями и миссией компании? Я еще верю в них? Или уже все пронизано цинизмом и пессимизмом?

Если ответы по двум из трех вопросов удручающие, пора валить.

Еще по теме:
How to waste your career, one comfortable year at a time

Напомню разницу: instance_double может уронить тест, если застабленные методы отсутствуют в указанном классе, double на все пофиг.

По моему опыту double нужен в двух случаях:
1. Вместо объекта, который пока не существует в системе. Нет класса, значит, instance_double не на что опереться.

2. Вместо чего-то незначительного со стабильным АПИ. Например, для писем:

allow(DeadlineMailer)
  .to receive(:last_deadline_warning)
  .and_return(double(:email, deliver_later: true))

Почему-то сталкиваюсь с такими тестами:

describe "#foo" do
  before :each do
    # ...
  end
end

:each можно смело опускать: это поведение по умолчанию для before. Лучше так:

describe "#foo" do
  before do
    # ...
  end
end

И несколько интересных фактов о before и after хуках:

1. before :each и before :all — алиасы для before :example и before :context.

2. before :each выполняется перед каждым примером, it do...end. after :each — после.

3. before :all выполняется перед контекстом (context, describe). after :all — после.

4. В before :suite нельзя задавать переменные экземпляра (instance var, @foo)

5. Только в before :each можно мокать.

Чтобы застабить в тесте переменную окружения, заглушите метод, с помощью которого код читает эту переменную:

# Если в коде ENV["CHARGES_TOKEN"]
allow(ENV)
  .to receive(:[])
  .with("CHARGES_TOKEN")
  .and_return("XXX")

# Если в коде ENV.fetch("CHARGES_TOKEN")
allow(ENV)
  .to receive(:fetch)
  .with("CHARGES_TOKEN")
  .and_return("XXX")

Если вы сторонник готовых гемов, возьмите для этой цели ClimateControl:

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

1. Бесполезные, общие слова, не несущие никакой конкретики:

it "adds certain value"
it "returns correct result"
it "fails"
it "returns formatted string"
it "returns correct url"
it "is ok"

2. Детали реализации:

it "changes @scheduled_on"
it "assigns @todos"

3. Ложь:

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

И, пожалуйста, не тестируйте конструкторы и attr_reader/writer/accessor: вы все равно их проверите, тестируя публичный АПИ.

Годами стайлгайдом для RSpec был betterspecs.org. К сожалению, он годами не менялся, не развивался и частенько не работал.

Оказывается, 1,5 года назад Better Specs стал RSpec Style Guide и переехал в Rubocop HeadQuarters:
https://github.com/rubocop-hq/rspec-style-guide

И стайлгайд ожил и расцвел:
https://rspec.rubystyle.guide

И, конечно, есть плагин к Рубокопу для работы со спеками:
https://github.com/rubocop-hq/rubocop-rspec

Подключается в два счета:

# Gemfile
gem "rubocop-rspec", require: false

# .rubocop.yml
require:
  - ...
  - rubocop-rspec

Полный список копов:
https://docs.rubocop.org/rubocop-rspec/cops_rspec.html

Недавно я опечатался в конфиге whenever:

every 1.day, at: "03:30 am", roles: %i(backupable) do
  rake %(
    backup:db
    backup:assets
  ).join(" ")
end

При деплое whenever взорвался:

NoMethodError: undefined method `join' for "backup:db backup:assets":String

Чтобы в будущем такого не было, нужна хотя бы минимальная валидация конфига whenever. Решение оказалось простым: достаточно запустить на CI:

bundle exec whenever

Если в конфиге есть проблемы, он взорвется ошибкой. Если проблем нет, выведет на экран получающийся кронтаб.

Проверка — фаза теста, в которой мы сверяем результат испытаний с правильным:

expect(post.slug).not_to be_nil
expect(account.admins).to match_array(admins)
expect(comment_notification).to have_received(:deliver)
expect { post.destroy }.to change(Post, :count).by(-1)

Тест, в котором много проверок, тяжело читать и поддерживать: чтобы найти упавшую проверку придется искать номер строки и читать соседние. Поэтому и советуют использовать одну проверку на тест.

Но бывают ситуации, в которых одна логическая проверка выражается несколькими физическими. Например, чтобы проверить, что цвет в RGB — это синий, проверяем красную, зеленую и синюю компоненту цвета:

describe "#color" do
  it "is blue" do
    expect(color.R).to be < 0.2
    expect(color.G).to be < 0.2
    expect(color.B).to be > 0.8
  end
end

В таких случаях лучше объединить проверки в одну с помощью have_attributes:

describe "#color" do
  it "is blue" do
    expect(color).to have_attributes(
      R: (a_value < 0.2),
      G: (a_value < 0.2),
      B: (a_value < 0.8),
    )
  end
end

А если проверить нужно несколько связанных сайд-эффектов, лучше объединить их с помощью and:

it "activates subscription" do
  expect { subscription.activate! }
    .to change { subscription.reload.active? }.to(true)
    .and change { subscription.reload.valid_until }.to(1.month.from_now)
end

Я фанат мгновенной обратной связи в тестах: чем быстрее я получу результаты теста, тем быстрее вернусь к коду, тем быстрее сделаю работу. Для этого использую вотчеры: в Руби Guard отслеживает изменения в файлах и автоматически запускает нужные спеки, в JS это делает jest –watch.

Постепенно они стали меня бесить: сохраняешь файл, тест прогоняется через две секунды. Эти две секунды — целая вечность. Часто думаешь, что не сохранил файл, сохраняешь еще раз. Тест прогоняется еще пару раз. Да еще и целиком!

Постепенно перешел к ручному, но мгновенному запуску тестов с помощью vim-test:
https://github.com/janko/vim-test

Идея простая: сохранил спеку, нажал «пробел t» (пробел — это leader), получил терминал с тестом. Мгновенная обратная связь, советую.

P. S. Для запуска тестов использую вот такие шорткаты:

nnoremap <silent> <Leader>t :TestFile<CR>
nnoremap <silent> <Leader>s :TestNearest<CR>
nnoremap <silent> <Leader>l :TestLast<CR>

У меня есть задротский курс по тестам в Руби и Рельсах. В нем я рассказываю, как проверять свою работу модульными и интеграционными тестами, как писать тесты так, чтобы потом их было легко читать и поддерживать.

До 30 марта отдаю его в четыре раза дешевле — за 250 рублей:
https://vasily.polovnyov.ru/tests/

Я сначала решил сделать его бесплатным, но понял, что хочу, чтобы вы все-таки прошли курс, а не сложили его в Покет в надежде прочитать когда-нибудь потом.

Независимый технический аудит проектов на Руби и Рельсах.

Для кого

Для тимлидов и техдиров, которые хотят взглянуть на код со стороны, найти проблемные места и исправить их. Для тех, кто хочет понять, как развивать код, команду и процесс разработки так, чтобы они приносили бизнесу больше денег.

Для соло-разработчиков, которые хотят писать понятный, лаконичный и идиоматичный код на Руби и Рельсах.

Как это работает

Мы вникаем в проект, созваниваемся, задаём вопросы и погружаемся в предметную область. Что делает проект? Для чего? Как он решает задачи бизнеса?

Затем просим доступ к коду. Оцениваем слабые места, предлагаем стратегии по их исправлению. Кроме кода и тестов оцениваем культуру разработки: что пишут в коммитах, что происходит в пулреквестах, как устроен деплой.

Проблемные места фиксируем, описываем и предлагаем исправления в трёх направлениях: образования разработчиков, требований к качеству кода и уверенности в коде.

На выходе — многостраничный гугль-док с результатами аудита и кучей дополнительных материалов: рекомендованной литературы, статей и видео по теме.

Кто проводит аудит

Меня зовут Василий Половнёв, последние пять лет я работаю ведущим разработчиком в Бюро Горбунова: отвечаю за сроки и качество. Специализируюсь на бэкенде, автоматизации и тестировании. Мне важно, чтобы разработчики делали качественные продукты и имели хорошую репутацию у продактов, тестировщиков и дизайнеров.

С чего начать

Если у вас команда до 10 человек и проект на Рельсах, которому нужен независимый аудит, пишите:
vasily@polovnyov.ru

Бывает, встречаю в спеках три отдельных теста на то, что полученный хэш в порядке: есть ключи, есть значения, у значений правильный тип.

RSpec.describe UserSerializer do
  describe "#as_json" do
    let(:user) do
      build(:user,
        first_name: "Bart",
        last_name: "Simpson",
        tel: "+777123")
    end
    let(:json) { described_class.new(user).as_json }

    it "has keys" do
      expect(json).to include(:first_name, :last_name, :tel)
    end

    it "has types" do
      expect(json[:first_name]).to be_kind_of(String)
      expect(json[:last_name]).to be_kind_of(String)
      expect(json[:tel]).to be_kind_of(String)
    end

    it "has values" do
      expect(json[:first_name]).to eq(user.first_name)
      expect(json[:last_name]).to eq(user.last_name)
      expect(json[:tel]).to eq(user.tel)
    end
  end
end

Такая спека скорее вредит, чем помогает: при изменении полей придется обновлять три теста; тяжело сразу понять, что именно возвращает сериалайзер. Лучше использовать лаконичный вариант:

RSpec.describe UserSerializer do
  describe "#as_json" do
    it "includes first name, last name and tel" do
      user = build(:user,
        first_name: "Bart",
        last_name: "Simpson",
        tel: "+777123")
      json = described_class.new(user).as_json

      expect(json).to include(
        first_name: "Bart",
        last_name: "Simpson",
        tel: "+777123"
      )
    end
  end
end

Регулярно встречаю тесты, в которых проверяют attr_reader:

class Alarm
  attr_reader :at

  def initialize(at: )
    @at = at
  end

  def snooze
    # ...
  end
end

RSpec.describe Alarm do
  describe "#at" do
    it "returns alarm time" do
      time = Time.now
      alarm = described_class.new(at: time)

      expect(alarm.at).to eq time
    end
  end
end

Это, конечно, бесполезно. Во-первых, так мы тестируем стандартную библиотеку — штуку, у которой уже есть собственные тесты. Зачем ей еще тесты?

Во-вторых, в таких тестах нет пользы, они проверяют тривиальное поведение.

В-третьих, геттер (Alarm#at) мы косвенно проверим в других тестах:

describe "#snooze" do
  it "snoozes alarm for nine minutes" do
    # ...

    expect { alarm.snooze }.to change { alarm.at }.by(9.minutes)
  end
end

P. S. ПРОТИП: если attr_reader нужен только самому объекту, его лучше сделать приватным:

private

attr_reader :repeat

Меня зовут Василий Половнёв, я веб-разработчик. Ищу сообразительного стажёра, который вместе со мной будет делать крутые бэкендерские штуки и со временем станет тимлидом.

Я ищу стажёра, который:

• отличает GET от POST, SELECT от UPDATE;
• отличает git rebase от git merge, пулреквест от реверта;
• знаком с Рельсами на уровне «написал блог за 15 минут, а потом пилил его по выходным»;
• слышал про RSpec, модульные и интеграционные тесты;
• не боится ни легаси, ни ПХП, ни фронтенда.

За полтора месяца научу стажёра:

• проверять свою работу модульными и интеграционными тестами;
• писать тесты быстрее, чем код;
• ревьюить, парно программировать и не унывать;
• быстро работать с Гитхабом, Рельсами и Семафором;
• находить и исправлять «запахи» в коде: от Long Method до Shotgun Surgery.

Для этого стажёр будет:

• работать 20 часов в неделю, часть времени — в паре со мной;
• тратить 2-3 часа в неделю на теорию и домашние задания;
• переписывать код снова и снова после ревью.

После стажировки мы либо продолжим работать вместе, либо стажер уйдёт на майские каникулы с планом роста и списком рекомендуемой литературы.

Если написанное выше про вас, напишите мне письмо с рассказом о себе на vasily@polovnyov.ru.

Если нет, поделитесь постом в соцсетях. Вот картинка для Фейсбука:

Смотрите:

it "builds tag slug from its title" do
  tag = Tag.new(name: "Веб-разработка", color: "#ccc")

  expect(tag.slug).to eq "veb-razrabotka"
end

Зачем тут color? На что он влияет? Как связан со slug и name? Чтобы ответить на все эти вопросы, придется покопаться в коде.

Бывает обратная ситуация:

it "builds tag slug from its title" do
  tag = build(:tag)

  expect(tag.slug).to eq "veb-razrabotka"
end

Почему veb-razrabotka? Откуда? От чего зависит? Чтобы ответить на эти вопросы, придется покапаться в фабриках.

Отсюда правило: в тесте должны быть данные, которые непосредственно влияют на проверку. Все остальное — под нож.

Смотрите, есть такой будильник:

class Alarm
  def to_human
    at.strftime("%k:%M").strip
  end
end

И такой тест:

it "returns alarm in human-readable 24-hour format" do
  time = Time.local(2019, 7, 7, 10, 35)
  alarm = described_class.new(at: time)

  expect(alarm.to_human).to eq "10:35"
end

Чтобы понять, достаточно ли этих тестов, я смотрю тестируемый модуль и спрашиваю себя: что тут особенного, если этот кусок кода удалить, какой тест упадет? Если никакой, то у меня 100% не хватает тестов или проверок.

В примере с будильником под вопросом .strip. Если удалить его, тест останется зеленым. Значит, не хватает теста:

it "strips any leading spaces" do
  time = Time.local(2019, 7, 7, 7, 15)
  alarm = described_class.new(at: time)

  expect(alarm.to_human).to eq "7:15"
end

Бывает, расшаришь с коллегой-разработчиком экран через Скайп и отлаживаешь что-нибудь странное в Айфоне. Оказывается, что проблема повторяется только на реальном устройстве, а в эмуляторе все ок.

Чтобы не пересказывать коллеге то, что происходит на экране телефона, можно расшарить его экран:

1. Открываем QuickTime
2. File — New Movie Recording
3. В выпадайке у кнопки записи выбираем Camera — iPhone
4. Скдыщ!

Бывает, встречаешь такое:

describe ".active" do
  let!(:active_accounts) { create_list(:active_account, 2) }
  before { create_list(:pending_account, 3) }

  it "returns only active accounts" do
    expect(described_class.active).to match_array(active_accounts)
  end
end

Сразу хочется спросить, почему часть зависимостей мы создаем в let, а часть — в before? Что за зависимости в before? Что здесь скрыто? Чаще всего ответ такой: мы не обращаемся к неактивным акаунтам в тесте, значит, и переменная не нужна — захерачим их в before.

Чтобы не ломать голову, лучше быть последовательным: использовать let для создания и указания зависимостей, а before — для приведения системы в нужное состояние:

describe ".active" do
  let!(:active_accounts) { create_list(:active_account, 2) }
  let!(:pending_accounts) { create_list(:pending_account, 3) }

  it "returns only active accounts" do
    expect(described_class.active).to match_array(active_accounts)
  end
end