Ок, спасибо, первую уже смотрю, вторую не слышал, гляну позже

да, именно это!
Как не крутил, Rspec этого пока не разрешает. Мне нужны репорты по сравнению каждой пары key-value из данных хешей. Думал, что если expect вставить в блок прогона .each, то и результаты будут выдаваться по каждой итерации. Но результат выдается по количеству it, а не по expect. А it вставить в цикл не разрешает, тест падает ошибкой
"NoMethodError:
 undefined method `data' for nil:NilClass."

Я еще не столь опытен в Rspec, возможно чего-то основного не ухватываю. Но пару дней уже безрезультатно "убил" на гугление  вопроса.

# frozen_string_literal: true

require 'rspec'

class HashDiffer;
end

EXPECTED_HASH = {
  foo: 42,
  bar: 'bar'
}.freeze

ACTUAL_HASH = {
  foo: 42,
  bar: 'bar'
}.freeze

describe HashDiffer do
  context :EXPECTED_HASH do
    EXPECTED_HASH.each do |key, value|
      it "value by key: #{key} from expected_hash to eq value by key: #{key} from actual_hash" do
        expect(value).to eq ACTUAL_HASH[key]
      end
    end
  end
end

Можно сделать что-то типа такого, конечно.
Но желательно иметь больше контекста задачи.
Что именно ты тестируешь? Это модульной (unit) тестирование методов класса?
Откуда берутся ожидаемые и реальные коллекции (hash)?

И почему ты хочешь иметь именно отдельные примеры на каждый ключ?
Суть теста какая? Можешь описать её просто русским языком?

Я хочу убедиться, что вот эти две коллекции равным между собой.
Или что-то другое?

Моя задача - сравнить статистические данные по объекту из определенной страницы сайта с подобными данными, которые по данному объекту выдает API (хотя объект один и тот же, данные для сайта и для API вычисляются немного разными алгоритмами и должны совпадать, поэтому нужны подробные проверки по каждому значению). Поэтому я с сайта Watir-ом загоняю данные в один хеш, а из API в другой хеш, потом сравниваю все значения в хешах.
Ранее этот тест я разработал на чистом Ruby и Logger-ом выводил подробные результаты по каждой паре сравниваемых значений. Сейчас перевожу тесты на Rspec и не могу добиться подобной подробности в результатах теста (результаты должен будет просматривать и менеджер проекта, они ему нужны удобочитаемые по каждому значению).

# frozen_string_literal: true

require 'rspec'

class HashDiffer;
end

EXPECTED_HASH = {
  foo: 42,
  bar: 'bar'
}.freeze

ACTUAL_HASH = {
  foo: 42,
  bar: 'bar'
}.freeze

describe HashDiffer do
  context :EXPECTED_HASH do
    EXPECTED_HASH.each do |key, value|
      it "value by key: #{key} from expected_hash to eq value by key: #{key} from actual_hash" do
        expect(value).to eq ACTUAL_HASH[key]
      end
    end
  end
end

как я понял из примера, фишка в том, чтобы хеш EXPECTED_HASH был определен еше перед
корневым describe?
У меня он создается и наполняется на начальном этапе в before(:all) внутри корневого describe.

Забавно, у меня пару лет назад был аналогичный тест (задача).
Сейчас нашёл в старом коде:

# frozen_string_literal: true

require_relative 'dataset'

describe VV4326, severity: :critical, quarantine: false do
  context :commision do
    before(:all) { @database_client = Database.o3 }
    after(:all) { @database_client.close }
    VV4326::DATASET.each do |data|
      context data do
        before :all do
          order_id = @database_client.query(VV4326::ORDER_ID_SQL).first.first
          access_token = @database_client.query(VV4326::ACCESS_TOKEN_SQL).first.first
          autologin_hash = @database_client.query(VV4326::AUTOLOGIN_HASH_SQL).first.first

          url = "http://.../v2/carrier/order/#{order_id}/commission?access_token=#{access_token}&bid=#{data}"
          response = HTTPClient.get url
          body = JSON.parse(response.body).symbolize_keys_recursively!
          @api_commission = body[:data]

          url = "http://.../api/suggestions/tariff?ah=#{autologin_hash}&bid=#{data}&oid=#{order_id}"
          response = HTTPClient.get url, header: { 'X-Api-Key' => '...' }
          body = JSON.parse(response.body).symbolize_keys_recursively!
          @site_tariff = body[:response]
        end
        it(:price_last) { expect(@api_commission[:price_last].to_i).to eq @site_tariff[:price_last].to_i }
        it(:price_commission) { expect(@api_commission[:price_commission].to_i).to eq @site_tariff[:price_commision].to_i }
        it(:price_commission_fee) { expect(@api_commission[:price_commission_fee].to_i).to eq @site_tariff[:price_commision_fee].to_i }
        it(:allowed) { expect(@api_commission[:allowed].to_i).to eq @site_tariff[:allowed].to_i }
        it(:max) { expect(@api_commission[:max].to_i).to eq @site_tariff[:max].to_i }
        it(:need) { expect(@api_commission[:need].to_i).to eq @site_tariff[:need].to_i }
        it(:bid) { expect(@api_commission[:bid].to_i).to eq @site_tariff[:bid].to_i }
        it(:additional_income) { expect(@api_commission[:additional_income].to_i).to eq @site_tariff[:additional_income].to_i }
      end
    end
  end
end

Там я делал тоже самое, только сверял ключи вручную, т. к. точно знал  структуру.
Плюс, у меня имена ключей в API и на Сайте могли отличаться.

p. s.: Зачем для сбора данных с сайта использовать Watir, если можно простым cURL запросом, что во много раз быстрее должно быть. Не требуется запуск браузера.

По поводу before и let.
Их внутренности доступны только внутри примера (it).
Всё, что идёт снаружи — должно снаружи и определяться.

# frozen_string_literal: true

require_relative 'dataset'

describe VV4326, severity: :critical, quarantine: false do
  context :commision do
    before(:all) { @database_client = Database.o3 }
    after(:all) { @database_client.close }
    VV4326::DATASET.each do |data|
      context data do
        before :all do
          order_id = @database_client.query(VV4326::ORDER_ID_SQL).first.first
          access_token = @database_client.query(VV4326::ACCESS_TOKEN_SQL).first.first
          autologin_hash = @database_client.query(VV4326::AUTOLOGIN_HASH_SQL).first.first

          url = "http://.../v2/carrier/order/#{order_id}/commission?access_token=#{access_token}&bid=#{data}"
          response = HTTPClient.get url
          body = JSON.parse(response.body).symbolize_keys_recursively!
          @api_commission = body[:data]

          url = "http://.../api/suggestions/tariff?ah=#{autologin_hash}&bid=#{data}&oid=#{order_id}"
          response = HTTPClient.get url, header: { 'X-Api-Key' => '...' }
          body = JSON.parse(response.body).symbolize_keys_recursively!
          @site_tariff = body[:response]
        end
        it(:price_last) { expect(@api_commission[:price_last].to_i).to eq @site_tariff[:price_last].to_i }
        it(:price_commission) { expect(@api_commission[:price_commission].to_i).to eq @site_tariff[:price_commision].to_i }
        it(:price_commission_fee) { expect(@api_commission[:price_commission_fee].to_i).to eq @site_tariff[:price_commision_fee].to_i }
        it(:allowed) { expect(@api_commission[:allowed].to_i).to eq @site_tariff[:allowed].to_i }
        it(:max) { expect(@api_commission[:max].to_i).to eq @site_tariff[:max].to_i }
        it(:need) { expect(@api_commission[:need].to_i).to eq @site_tariff[:need].to_i }
        it(:bid) { expect(@api_commission[:bid].to_i).to eq @site_tariff[:bid].to_i }
        it(:additional_income) { expect(@api_commission[:additional_income].to_i).to eq @site_tariff[:additional_income].to_i }
      end
    end
  end
end

Спасибо большое за реальный пример!
да, в нем логика двух хешей та же, только для каждой пары сравниваемых значений вручную был создан отдельный it (если я правильно понял).
У меня же количество таких пар может достигать нескольких десятков для разных объектов (суть сайта именно в этой статистике), поэтому я и хотел "загнать" эти проверки в each, чтобы it-ы создавались как-бы автоматически.
P.S.: Да, сURL запросом будет намного быстрее, но хотелось сравнить именно то, что видит реальный юзер, поэтому остановился на сборе данных Watir-ом (таких больших тестов не так много, так что скорость тут не критична).

замечательно, остается обмозговать как это реализовать в моей ситуации, благодарю премного!

Всегда рад помочь, особенно по Ruby/RSpec.
Если мы тут в чате мешаем любителям Python :), то смело пишите мне в почту sblohin@yandex.ru или в ЛС Телеграма.

Добро, спасибо!

> поэтому я и хотел "загнать" эти проверки в each, чтобы it-ы создавались как-бы автоматически
Если у тебя ключи в хешах совпадают, то я никак не могу понять необходимости в отдельных примерах на каждый ключ.
Разве для прогона теста не будет достаточным ответ ХЕШИ СОВПАДАЮТ или ХЕШИ НЕ СОВПАДАЮТ?
Разбивать на разные примеры имеет смысл в случае, когда ключи разные, или когда когда значения подобных ключей могут (допустимо могут) отличаться классом или форматом, и для них требуется отдельны предпроцесснинг.

"Разбивать на разные примеры имеет смысл в случае, когда ключи разные, или когда когда значения подобных ключей могут (допустимо могут) отличаться классом или форматом, и для них требуется отдельны предпроцесснинг."
- да, ключи разные, в предпроцессинге я их привожу к единообразию, а также значения к единообразному формату, поэтому там немного сложнее.

"Разве для прогона теста не будет достаточным ответ ХЕШИ СОВПАДАЮТ или ХЕШИ НЕ СОВПАДАЮТ?"
Для эффективности анализа результатов не достаточно.
При результате "F" Rspec выводит сообщение о только одном различии пар значений (на которое он наткнулся при прогоне в первую очередь наверное). А если различия есть в нескольких парах (как в реальном теперешнем случае)? Полный список различий в результатах не выводится.

Привет всем! Кто-нить знает как заблочить third party resources для Firefox? Для хрома нашел такую опцию options.add_argument("--host-resolver-rules)

/me ушёл читать, что такое «third party requests»

К примеру, гугл аналитика

Задача сводится к тому, чтобы в тестах открывался браузер, загружался целевой сайт, но при этом не шли запросы на определённые адреса (ГА, например)?

+

iptables