<div>Other solution is to use instance_variable_get and instance_variable_set methods.</div><div><a href="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_get</a></div>
<div><a href="http://ruby-doc.org/core-1.9.3/Object.html#method-i-instance_variable_set">http://ruby-doc.org/core-1.9.3/Object.html#method-i-instance_variable_set</a></div><div><br></div><div><div>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].</div>
</div><div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">class Box</span></div><div> attr_accessor :item<br style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">end</span></div><div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">describe Box do</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); "> it { should define_attr_accessor_for :item }</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">end</span></div>
<div><br></div><div><br></div><div>[1]</div><div><a href="https://github.com/dchelimsky/rspec/wiki/Custom-Matchers">https://github.com/dchelimsky/rspec/wiki/Custom-Matchers</a></div><div><br></div><div>[2]</div><div>Recommend to check the following article too.</div>
<div><a href="http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/">http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/</a></div><div><br></div><div><br></div><div>Cheers,</div><div><br></div>
<div>Tatsuya</div><div><br></div><div class="gmail_quote">On 22 November 2011 18:03, Sam Livingston-Gray <span dir="ltr"><<a href="mailto:geeksam@gmail.com">geeksam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
+1 to what Tom said. Duplication was the smell; the underlying cause<br>
was that you're thinking about your code from the wrong perspective.<br>
(= In this case, deleting one of the tests and renaming the other (it<br>
"holds an item for later retrieval", perhaps?) would be a good first<br>
step.<br>
<br>
That being said, I'm more tolerant of duplication in my tests than in<br>
my code under test. I've also been discovering that having a few<br>
integration tests written first (in a top-down style) can make<br>
refactoring easier. I've tended to do bottom-up TDD, which creates<br>
API inertia (in that changing the public interface of classes is more<br>
likely to break tests); if I've not yet reached a point where I have a<br>
higher-level test that specifies something the user cares about, it's<br>
very easy to either go down a rathole ("fix ALL the tests!") or give<br>
up and accept a subpar API because too many things go red.<br>
<br>
Incidentally, I was listening to an interesting podcast interview with<br>
Gary Bernhardt yesterday. Among other things, it touched on different<br>
approaches to testing; might be a good start to further exploration.<br>
<a href="http://www.engineyard.com/podcast/s01e40-gary-bernhardt" target="_blank">http://www.engineyard.com/podcast/s01e40-gary-bernhardt</a><br>
<font color="#888888"><br>
-Sam<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Tue, Nov 22, 2011 at 3:31 AM, Tim Cowlishaw <<a href="mailto:tim@timcowlishaw.co.uk">tim@timcowlishaw.co.uk</a>> wrote:<br>
> On Tue, Nov 22, 2011 at 11:29 AM, Tom Stuart <<a href="mailto:tom@experthuman.com">tom@experthuman.com</a>> wrote:<br>
><br>
>> Spec behaviour, not implementation. I'd have a single example that covers the behaviour "when I put a value, get should return that value".<br>
><br>
> Aah ok, that makes far more sense - I've tended to tie my specs quite<br>
> closely to the interface being exposed in the past (ie, at least one<br>
> spec per public method per class), but I guess there's no real need<br>
> to.<br>
><br>
> Thanks!<br>
><br>
> Tim<br>
> _______________________________________________<br>
> Chat mailing list<br>
> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
><br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br>