[LRUG] A question on DRYness on testing methods that get / set state
James Cumming
james.cumming at yahoo.co.uk
Wed Nov 23 02:28:44 PST 2011
> 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
Interesting interview this was. Has anyone used classes in the lib folder extensively as Gary suggests? How have you found it?
I can think of a few of my projects where this make sense and hopefully speed up autotest.
Cheers
James Cumming, CFA
+44 7799 554468
________________________________
From: Sam Livingston-Gray <geeksam at gmail.com>
To: London Ruby Users Group <chat at lists.lrug.org>
Sent: Tuesday, 22 November 2011, 18:03
Subject: Re: [LRUG] A question on DRYness on testing methods that get / set state
+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/20111123/960e4ba8/attachment-0003.html>
More information about the Chat
mailing list