[LRUG] A question on DRYness on testing methods that get / set state

[Tatsuya Ono]

Other solution is to use instance_variable_get and instance_variable_set
methods.
http://ruby-doc.org/core-1.9.3/Object.html#method-i-instance_variable_get
http://ruby-doc.org/core-1.9.3/Object.html#method-i-instance_variable_set

However I would use attr_accessor instead of put/get method in this case. I
do not write spec for each attributes usually to be honest, but we could
also write a custom matcher[1] for attr_accessor if needed. Both
implementation and its spec will be clean like below [2].

class Box
  attr_accessor :item
end

describe Box do
  it { should define_attr_accessor_for :item }
end


[1]
https://github.com/dchelimsky/rspec/wiki/Custom-Matchers

[2]
Recommend to check the following article too.
http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/


Cheers,

Tatsuya

On 22 November 2011 18:03, Sam Livingston-Gray <geeksam at gmail.com> wrote:

> +1 to what Tom said.  Duplication was the smell; the underlying cause
> was that you're thinking about your code from the wrong perspective.
> (=  In this case, deleting one of the tests and renaming the other (it
> "holds an item for later retrieval", perhaps?) would be a good first
> step.
>
> That being said, I'm more tolerant of duplication in my tests than in
> my code under test.  I've also been discovering that having a few
> integration tests written first (in a top-down style) can make
> refactoring easier.  I've tended to do bottom-up TDD, which creates
> API inertia (in that changing the public interface of classes is more
> likely to break tests); if I've not yet reached a point where I have a
> higher-level test that specifies something the user cares about, it's
> very easy to either go down a rathole ("fix ALL the tests!") or give
> up and accept a subpar API because too many things go red.
>
> Incidentally, I was listening to an interesting podcast interview with
> Gary Bernhardt yesterday.  Among other things, it touched on different
> approaches to testing; might be a good start to further exploration.
> http://www.engineyard.com/podcast/s01e40-gary-bernhardt
>
> -Sam
>
>
>
> On Tue, Nov 22, 2011 at 3:31 AM, Tim Cowlishaw <tim at timcowlishaw.co.uk>
> wrote:
> > On Tue, Nov 22, 2011 at 11:29 AM, Tom Stuart <tom at experthuman.com>
> wrote:
> >
> >> Spec behaviour, not implementation. I'd have a single example that
> covers the behaviour "when I put a value, get should return that value".
> >
> > Aah ok, that makes far more sense - I've tended to tie my specs quite
> > closely to the interface being exposed in the past (ie, at least one
> > spec per public method per class), but I guess there's no real need
> > to.
> >
> > Thanks!
> >
> > Tim
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20111122/01880bbc/attachment.html>