Rail and TDD, what do you test?

Hi, I’m reading RoR e-commerce and I’ve discovered that they test also
tag like h1, form and other… When you use TDD with rails what do you
test? also tag like title, table, etc? i think it’s useful to test
something that it’s necessary to be there in a certain style or
something like a certain title, but what do you think?

mike wrote:

Hi, I’m reading RoR e-commerce and I’ve discovered that they test also
tag like h1, form and other… When you use TDD with rails what do you
test? also tag like title, table, etc? i think it’s useful to test
something that it’s necessary to be there in a certain style or
something like a certain title, but what do you think?

Normally I don’t test the “content” type tags. I’ll test that the
correct links are present, that the correct form is present with the
required fields, that any important dynamic text is there. In general
I feel you want to keep the actual HTML rather fluid so that a designer
can work their magic without breaking the tests. Regrading style
attributes, no, I wouldn’t do that. I would be willing to test that an
appropriate id/class was assigned to a page element, but only if I’m
still at a semantic level.

However if you have various accessibility guidelines or requirements,
I’d probably test for those too, but I suspect I’d end up wrapping those
up into a custom assertion so I can easily update the cross-site
requirements and not have to fiddle with each individual
test/view/action too much.

mike wrote:

Hi, I’m reading RoR e-commerce and I’ve discovered that they test also
tag like h1, form and other… When you use TDD with rails what do you
test? also tag like title, table, etc? i think it’s useful to test
something that it’s necessary to be there in a certain style or
something like a certain title, but what do you think?

TDD generally means “test-first” programming. For a back-end module,
TFP provides incredible visibility. For code running in or just under
a GUI, you already get a lot of visibility by running the GUI.

The guideline for TFP in a back-end module is “test-first everything
you need to work”. If you don’t need something to work, you ought to
not write it, so that generally means to TFP everything.

The guideline for TFP in a GUI is less strict. “Test-first everything
that might break invisibly.” If you switch a background color to pink,
and if a bug turns it green, you can see that immediately. (Further,
if you like the green, you can ignore the bug and keep going.)

I like to call test-free programming, in a GUI, “authoring”. That’s
the equivalent of using an editor to write HTML. It’s not really
programming; it’s just scripting an existing program. You are not
writing a new browser, so don’t TFP your pink background color.


Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!