[rspec-users] RSpec makes me want to write better code

Mark Wilden mark at mwilden.com
Fri Sep 26 18:38:29 EDT 2008

On Fri, Sep 26, 2008 at 3:10 PM, David Chelimsky <dchelimsky at gmail.com>wrote:

> Now sometimes there will be some up-front modeling discussions and you
> may have a sense that a model needs a specific set of fields just
> because that's what the customer says. In those cases, I'd recommend
> trying to find something about the object's behaviour to rationalize
> the presence of those fields.

I think I know what you mean, and I would reply with two points, one agile,
and one not so agile:

1) In a test-driven environment, you don't write code until you write a
failing test. Now, unless you mean to spread your table definition across
multiple migrations, that means you would have to write a spec for
Demographics Reports before you could create your table. By testing
attributes directly, you can indeed write a failing spec, then make it pass
by writing a migration. It's not a huge deal, because you could indeed write
multiple migrations as you define clients of the data.

2) The second is more important, however, and has to do with the non-agile
nature of databases. Put simply, you can't change database content like you
can change code. The example I used to use (probably outdated now) is fax
number. If you're writing a customer relationship management system, you
might want to store customer fax numbers _even if you have no use for them_.
The reason is simply that if you _do_ need them later, you can't go back and
get them. In other words, databases can have a prophecy requirement that
ever-malleable code does not.

All that said, I think your developer's conversation with the customer is
very apt. In many if not most cases, if there's no output for the data,
there's no need for its input. But not always.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080926/55f06256/attachment.html>

More information about the rspec-users mailing list