I encountered a unlucky behavior of byebug 11.1.3 (the most recent version at time of writing) when using it with Rails 6 and it's new autoloading component, zeitwerk. There already is a issue Show archive.org snapshot for that, so I hope it will be fixed with a future release.
The following test succeeds:
context 'factories' do
let(:test_case) { FactoryBot.create(:test_case) }
it 'are valid' do
expect(test_case).to be_valid
end
end
But when I did the same in byebug the following happened:
(byebug) FactoryBot.create(:test_case)
*** NameError Exception: uninitialized constant #<Class:0x000055580a8e7918>::TargetLimitation
Did you mean? TargetsTestScenario
It seems like Byebug does not work well with zeitwerk. There is already a patch in
Ruby 3.1
Show archive.org snapshot
, that would allow Byebug to solve the issue. But at the time of writing only
ruby/debug
Show archive.org snapshot
implemented the fix and uses TracePoint.allow_reentry
. The
issue for Byebug
Show archive.org snapshot
is still open.
Solutions
Good: Use a different debugger
Jard
Show archive.org snapshot
seems also to have problems with zeitwerk, since the create statement just didn't return.
Pry
Show archive.org snapshot
(binding.pry) worked without problems for me. Note: In case you are using pry-byebug
, you need to replace it with pry
. Otherwise binding.pry
is still broken.
Neutral: Use eager loading in tests
Eager loading means all classes are loaded before the code starts executing. Be aware that this could have an impact on the performance of tests.
config/environments/test.rb
:
config.eager_load = true
Bad: Switch back to use the classic autoloading
config/application.rb:
config.autoloader = :classic
Your choice of debugger should not force you to use old/different settings in the whole application. You can do that temporarily though.
Even more bad: explicitly require
the not found class
This will leave you with a mess of requires
that has to be maintained and be cleaned up in the future. You can do that temporarily though.
Also quite bad: Explicitly mention the class before your debugger statement
# ... (code)
TestCase::TargetLimitation
debugger
# ... (more code)
This will leave you with a mess of calls to the class that has to be maintained and be cleaned up in the future. You can do that temporarily though.