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

David Chelimsky dchelimsky at gmail.com
Fri Sep 26 19:16:28 EDT 2008

On Fri, Sep 26, 2008 at 5:38 PM, Mark Wilden <mark at mwilden.com> wrote:
> 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.

This is really a deficiency of ActiveRecord migrations in my view.
DataMapper, for example, offers auto-migrations. You just add a
property to your model file and it takes care of the migration for
you. Of course, the way it does this is to drop the table and re-write
it, so you don't want to do THAT in production :) But for agile dev,
it's a much nicer process.

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

I flatly disagree with this. Data is not inherently non-agile. But
some processes for managing the evolution of data are.

If you don't need it now, or can't even justify the need for it in the
future, then it doesn't belong in the code OR in the data. If somebody
thinks "we might need it later" then it should be discussed as a
requirement and either introduced as one or dropped. If "we might need
it later" then probably somebody has a good argument why. If nobody
can think of a good reason, then why add the extra weight to the db
AND to the examples. Not to mention the fact that fax numbers are
going to need some sort of format validation, which is going to be
code that costs money to write and maintain.

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

I would agree with "but not always." But, I'd say that in the "not
always" exceptions there should be a huge red flag and serious
discussion about why requirements are being imposed on a system for
which nobody can argue business value.


> ///ark

More information about the rspec-users mailing list