Встроенная поддержка ISO 8061 в RSpec или Minitest

Если цель теста — проверить правильность преобразования пары pin_code_sent_at в JSON, вы можете упростить это с помощью have_attributes. Вы можете протестировать отдельные ключи без необходимости менять тест каждый раз при добавлении ключа.

expect(parsed_body).to have_attributes(
  "pin_code_sent_at": user.pin_code_sent_at.utc.iso8601(3)
)

Вы также можете просто просмотреть ожидаемые данные через JSON и посмотреть, совпадают ли они. Это называется «круглым циклом», гарантирующим правильную сериализацию и десериализацию данных. Это нормально, вы не тестируете парсер JSON, вы проверяете, были ли ему переданы правильные данные. Это позволяет избежать ложных сбоев теста при изменении деталей форматирования JSON.

expect(parsed_body).to have_attributes(
  JSON.parse({ pin_code_sent_at: user.pin_code_sent_at }.to_json)
)

Если вы часто этим занимаетесь, вы можете написать собственное средство сопоставления.

RSpec::Matchers.define :have_json_attributes do |expected|
  match do |actual|
    expect(actual).to have_attributes(JSON.parse(expected.to_json))
  end
end

expect(parsed_body).to have_json_attributes(
  pin_code_sent_at: user.pin_code_sent_at
)

(Что-то в этом роде, сейчас я не могу это проверить.)

Вы столкнулись с этой проблемой, потому что JSON.parse не воссоздает объект времени:

t = Time.parse('2024-08-30T14:30+0000')

data = { key: t }
#=> {:key=>2024-08-30 14:30:00 +0000}

json = data.to_json
#=> "{\"key\":\"2024-08-30T14:30:00.000+00:00\"}"

parsed_body = JSON.parse(json)
#=> {"key = ">"2024-08-30T14:30:00.000+00:00"

Как видите, значение :key/"key" изменилось с экземпляра Time на экземпляр String. Такое поведение ожидается из документации JSON:

Когда вы «перемещаете» объект, не являющийся строкой, из Ruby в JSON и обратно, у вас есть новая строка вместо объекта, с которого вы начали.

Затем в документации объясняются так называемые дополнения JSON, которые добавляют детали класса в строку JSON для анализа. Но я думаю, что это не вариант, поскольку он существенно изменит сгенерированный JSON и работает только для Ruby.

Однако более простой способ получить сопоставимую структуру — получить JSON-представление объекта времени через as_json из поддержки JSON ActiveSupport. Соответствующий ключ может быть задан в виде буквальной строки:

expect(parsed_body).to eq({ "key" => t.as_json })

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

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

Вариации представления

Рельсы

Преобразование объекта Time в стандарт ISO 8601 реализуется Rails по умолчанию. Источник и Источник .

Реализация ISO 8601 в Rails основана исключительно на общем соглашении, рекомендации этого формата в RFC 7493 и на том факте, что этот стандарт хорошо известен и широко используется, что делает его более переносимым, чем большинство других.

Интересно, что если настройка to_json в Rails отключена, вы получите ActiveSupport::JSON::Encoding::use_standard_json_time_format

JSON драгоценный камень

Гем Ruby JSON просто вызывает "%Y/%m/%d %H:%M:%S %z" (для большинства объектов), что в случае объекта to_s не является соответствующим стандартом Time

Это создает дополнительную путаницу, поскольку "%Y-%m-%d %H:%M:%S %z" имеет другое представление DateTime, соответствующее RFC 3339. to_s

О Джей

Драгоценный камень oj использует свой собственный подход, представляя "%Y-%m-%dT%H:%M:%S%z" как Time. Это позволяет сохранить объект в формате json и преобразовать этот json обратно в объекты Ruby, но только если обе стороны используют реализацию этой библиотеки.

и т. д...

Туда и обратно

Как вы можете видеть, из-за отсутствия реального стандарта круговой обмен JSON затруднен, и парсер должен либо реализовать свой собственный вариант представления (например, {\"^t\": precision_seconds_since_the_epoch}), либо его нужно будет спроектировать для обработки любого количества возможных представления, чтобы сначала определить, является ли oj датой, а затем преобразовать ее, что, как вы понимаете, может занять много времени и привести к ошибкам.