[LRUG] A question on DRYness on testing methods that get / set state
Daniel Barlow
dan at telent.net
Wed Nov 23 02:29:52 PST 2011
> On 23 November 2011 16:32, Graham Ashton <graham at effectif.com> wrote:>>>> So if we were using attr_* to implement the feature (I realise it's a>> contrived example) I'd skip the test entirely as I'd just be testing Ruby>> (which is pointless).
Are you writing tests against a (perhaps unwritten/verbal/implicit)
external specification, or are you writing the spec? At some point
the focus of "agile" advocates - or, as we like to refer to them these
days, "all right-thinking people" - changed from "test everything that
could possibly break" (XP, back in the days when that was fashionable)
to "your test is a specification of how the application should behave"
(TDD/BDD).
In this case it's frustrating, I feel, because "attr_accessor :foo" in
a source file is just as declarative as
"has_something_that_behaves_like_an_accessor :foo" in a spec file - it
just happens that unfortunately it's written in the wrong place to be
considered as specification. Personally, for any test like this
where a reasonable implementation can be inferred from the
specification (you could also express this as "the specification is
executable") I would like to see some way of directing the interpreter
to do so - perhaps some kind of tool which reads your spec files and
generates implementation for the easy bits. It could of course be
told not to when you want to do something more complicated instead.
But what do I know? It probably exists already.
More information about the Chat
mailing list