I’m a little conflicted about how and if one should write test code for declarative code. Let’s say I’m writing a MongoMapper document class. It might look something like this:
class Issue include MongoMapper::Document key :title, String key :body, String key :created_at, DateTime end
Those key calls. Should I write a test for them? In the past, I’ve said “yes” on the principle that I was test driving the code and I needed something to fail in order to add code. Further, the growing ML-style-typing geek within me likes that writing tests for this is somewhat like constructing my open wacky type system via the test suite.
A Shoulda-flavored test might look something like this:
class IssueTest < Test::Unit::TestCase
context 'An issue' do
should_have_keys :title, :body, :created_at
end
end
Ignoring the recursive rathole that I’ve now jumped into, I’m left with the question: what use is that should_have_keys? Will it help someone better understand Issue at some point in the future? Will it prevent me from naively breaking the software?
Perhaps this is the crux of the biscuit: by adding code to make certain those key calls are present, have I address the inherent complexity of my application or have I imposed complexity?
I’m going to experiment with swinging back towards leaving these sorts of declarations alone. The jury is still out.
I’d say leave that test out, and also leave the key declarations out until they’re storing data you need for some behaviour. I presume the ‘key’ statements both set up (a) an accessor on the attribute, and (b) persistent storage of the values – testing plain readers/writers doesn’t gain much IMO, and you’ll be testing storage in general at higher level tests.
You make a good point about testing accessors. However, I like the _idea_ of testing the contract of a class, and accessors are certainly part of the contract. But liking the idea does not mean I’m going to stick with it in practice ;)
I’ve had this exact same problem, but I don’t know the answer :(
I wrote a bunch of rspec macros to reduce my previously multi-line specs which test various model declarations down to a single line, but then found myself in the same situation you describe…
My thinking at the moment is that duplicating a model declaration with a spec declaration is pointless, and not very dry. Any getter/setter tests should be abstracted up to the DSL library level and the model declarations left to speak for themselves. I could be wrong though :)