← Back to Upcase

Testing Null Objects


(Geoff Harcourt) #1

I had a question about @georgebrock’s excellent article about testing null objects. I have a null object that’s a stand-in for Address, which is an ActiveRecord model. There are a lot of methods on Address that are things I would never expect to call in a view, such as #autosave_associated_records_for_addressable. It seems like adding methods to my NullAddress here just to make the matcher work is overkill.

I’ve tried filtering out methods from ActveRecord::Base.instance_methods, but there are still a number of dynamically generated methods that clutter the list of methods in the public interface of Address. How do folks handle this? I would really like to be able to cleanly track the public interface of my models and null objects together, but it seems difficult to figure out a sensible list that doesn’t require creating a bunch of useless, crufty methods on my null object.


(Samnang Chhun) #2

For me, I don’t test all methods from that model, so what I test are only public interface of that model that I call from my controllers and service objects. But if you go with the route to make sure support all interfaces of that model, so you could check out Naught, then lets Naught figure out for you. I haven’t used Naught in my real application yet.