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