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:
[sourcecode language=“ruby” gutter=“false”] class Issue
include MongoMapper::Document
key :title, String key :body, String key :created_at, DateTime
end [/sourcecode]
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:
[sourcecode language=“ruby” gutter=“false”] class IssueTest < Test::Unit::TestCase
context ‘An issue’ do
should_have_keys :title, :body, :created_at
end
end [/sourcecode]
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.
