But it doesn't implement respond_to_missing? accordingly, leading to surprising behavior when using rspec matchers for example:
irb(#<RSpec::ExampleGroups::InvoiceResource::Including:0x00007a48fac318e8>):048:0> node = GraphitiSpecHelpers::Node.new({foo: 1, bar: 2}, nil, nil)
=> #<GraphitiSpecHelpers::Node:0x00007a48fa9fb010 @attributes={"foo"=>1, "bar"=>2}, @context=nil>
irb(#<RSpec::ExampleGroups::InvoiceResource::Including:0x00007a48fac318e8>):049:0> node.foo
=> 1
irb(#<RSpec::ExampleGroups::InvoiceResource::Including:0x00007a48fac318e8>):050:0> expect(node).to have_attributes(foo: 1)
/opt/bundle/ruby/3.2.0/gems/rspec-support-3.13.1/lib/rspec/support.rb:110:in `block in <module:Support>': expected #<GraphitiSpecHelpers::Node:0x00007a48fa9fb010 @attributes={"foo"=>1, "bar"=>2}, @context=nil> to respond to :foo with 0 arguments (RSpec::Expectations::ExpectationNotMetError)
from /opt/bundle/ruby/3.2.0/gems/rspec-support-3.13.1/lib/rspec/support.rb:119:in `notify_failure'
from /opt/bundle/ruby/3.2.0/gems/rspec-expectations-3.13.0/lib/rspec/expectations/fail_with.rb:35:in `fail_with'
from /opt/bundle/ruby/3.2.0/gems/rspec-expectations-3.13.0/lib/rspec/expectations/handler.rb:40:in `handle_failure'
from /opt/bundle/ruby/3.2.0/gems/rspec-expectations-3.13.0/lib/rspec/expectations/handler.rb:56:in `block in handle_matcher'
from /opt/bundle/ruby/3.2.0/gems/rspec-expectations-3.13.0/lib/rspec/expectations/handler.rb:27:in `with_matcher'
from /opt/bundle/ruby/3.2.0/gems/rspec-expectations-3.13.0/lib/rspec/expectations/handler.rb:48:in `handle_matcher'
from /opt/bundle/ruby/3.2.0/gems/rspec-expectations-3.13.0/lib/rspec/expectations/expectation_target.rb:65:in `to'
from /opt/bundle/ruby/3.2.0/gems/rspec-expectations-3.13.0/lib/rspec/expectations/expectation_target.rb:101:in `to'
from /usr/src/app/hitobito/spec/resources/invoice/reads_spec.rb:50:in `block (3 levels) in <top (required)>'
from /usr/src/app/hitobito/spec/resources/invoice/reads_spec.rb:54:in `block (3 levels) in <top (required)>'
from /opt/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:263:in `instance_exec'
from /opt/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:263:in `block in run'
from /opt/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:511:in `block in with_around_and_singleton_context_hooks'
from /opt/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/lib/rspec/core/example.rb:468:in `block in with_around_example_hooks'
from /opt/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:486:in `block in run'
from /opt/bundle/ruby/3.2.0/gems/rspec-core-3.13.0/lib/rspec/core/hooks.rb:626:in `block in run_around_example_hooks_for'
... 69 levels...
irb(#<RSpec::ExampleGroups::InvoiceResource::Including:0x00007a48fac318e8>):051:0> node.respond_to?(:foo)
=> false
GraphitiSpecHelpers::Node
allow to access the underlying attributes directly with it'smethod_missing
implementation:https://github.com/graphiti-api/graphiti_spec_helpers/blob/master/lib/graphiti_spec_helpers/node.rb#L42C1-L49C8
But it doesn't implement
respond_to_missing?
accordingly, leading to surprising behavior when using rspec matchers for example: