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

[Sam Livingston-Gray]

+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
>