We discovered that our runtime code in production had an expectation to be able to call symbolize_keys on a Ruby hash even though we had no dependency on activesupport. The tests flexed this code and passed. I was able to produce an example script that illustrates that factory_bot is injecting code into base classes which can mask production issues during test.
Reproduction Steps
begin
{}.symbolize_keys
rescue NoMethodError => e
puts "\e[31m------ WARNING ----- Hashes do not respond to symbolize_keys ---------\e[0m"
end
require 'bundler/inline'
gemfile(true) do
source 'https://rubygems.org'
group :development, :test do
gem 'factory_bot'
end
end
require 'factory_bot'
puts "FactoryBot Version: #{FactoryBot::VERSION}"
begin
{}.symbolize_keys
puts "\e[31m------ WARNING ----- Hashes now respond to symbolize_keys ---------"
puts "This behavior is introduced by ActiveSupport\e[0m"
rescue NoMethodError => e
puts " ------------ EXPECTED ---- Hashes still do not respond to symbolize_keys"
end
Expected behavior
FactoryBot should not change behavior of classes it does not own.
Description
We discovered that our runtime code in production had an expectation to be able to call
symbolize_keys
on a Ruby hash even though we had no dependency on activesupport. The tests flexed this code and passed. I was able to produce an example script that illustrates that factory_bot is injecting code into base classes which can mask production issues during test.Reproduction Steps
Expected behavior
FactoryBot should not change behavior of classes it does not own.
Actual behavior
the
EXPECTED
line prints in the above script.System configuration
factory_bot version: 6.4.6 rails version: NA ruby version: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin23]