Phlip | 16 Nov 20:27 2006

Re: Test driving a real world data parser

Tim Ottinger wrote:

> Personally I like the advice to clean it up with tidy. Tidy is awesome.

Then, XPath is a sledge-hammer to TDD raw HTML.

(Note - sometimes you just write the HTML, and sometimes you TDD at
another level. When you TDD at the HTML surface itself, use XPath.)

Here's a sample of my current project:

<at> xdoc =
assert_xpath "/span/input[ <at> name = 'frob[id]' and <at> value = '#{}']"

assert_xpath "/span/script[ <at> type = 'text/javascript']" do |node|
assert_equal "Form.Element.disable('frob_zone_mode_1');", node.text()

The first xpath asserts that we generated a span containing a (hidden)
input field with the given value.

The second xpath asserts this span also contains a script. Then a
nested assertion checks the script contains the right JavaScript.

My assert_xpath can nest calls to more assert_xpath, and they will
work on the selected node. So I could, for example, start at a form,
then drill down and inspect fields in the form.

The general principle here is one can TDD a scripting language by
driving a parser which reads that scripting language. And so this
leads to the ideal that we should only select scripts for which
parsers are available!

Phlip <-- NOT a blog!!

Recent Activity
Visit Your Group
Yahoo! Mail

You're invited!

Try the all-new

Yahoo! Mail Beta

Y! Messenger

Group get-together

Host a free online

conference on IM.

New web site?

Drive traffic now.

Get your business

on Yahoo! search.


Phlip | 1 Dec 20:35 2006

[TFUI] Re: [XP] What's up with Rails?

Shane Mingins wrote:

> That currently would be my sentiment too. I am hoping to use Rails
> more.

The best accolade for Ruby, so far, comes from the Pragmatic Programmers:

Ruby stays out of your way

That's a good way to say that Ruby has a user-interface tuned for
programmer's needs. (It's also an excuse why Ruby puts the needs of the
programmer above those of the CPU!)

I thought of a similar accolade for Rails:

Rails shortens the distances between two points

Under classical web programming, you typically must add a variable to both
the SQL and HTML, then you must spend hours adding plumbing and
infrastructure to link the two.

Rails flattens that problem. You can often add a variable to the SQL, match
it in the HTML, and add _nothing_ in between. Rails took care of the
plumbing for you. And if you need that variable in the controller layer, to
add business logic, then it's usually ready and waiting for you.

> I have just read Cody Fauser's RJS Template for Rails which had
> a link about TDD RJS. I have yet to try it out. It may be of
> interest to you if you have not already seen it.

I rebutt that effort (although I am almost about to use it myself). It's a
good first start, but it's not really TDD as we know it. I will explain why,
starting with a simpler HTML example.

(RJS is a module that generates JavaScript, so you can minimize swapping
between languages, not worry about escapes, etc...)

If I wrote HTML, it might look like: <em>yo<strong>dude</em></strong>.

So this is not a good test for that:

assert_equal '<em>yo<strong>dude</em></strong>', my_html

We wouldn't do that for TDD on the Logic Layer, so we shouldn't accept it
for the GUI Layer. It only tests that an intermediate artifact trivially
matches our test reference.

And it didn't catch the bug - the tags are not nested.

assert_rjs is a very pretty, high-level way to do just this. It does not
test that RJS emitted JavaScript that indeed updates one of our panels, and
indeed turned another panel blue. Instead, it trivially tests that the
production code emitted the JavaScript said it would emit.

Here's the RJS to update a panel:

page.replace_html 'span_id', '<em>yo<strong>dude</strong></em>'

That is light-years more convenient than the equivalent 200 lines of
portable and browser-neutral JavaScript. But is this a valid test for it?

assert_rjs :replace_html, 'span_id', '<em>yo<strong>dude</strong></em>'

It's a decorated form of a Log String Test. It treats the RJS page object as
a mock object that absorbs a string recording all its calls, then it
trivially matches that the page object contains JavaScript matching all
those calls.

Bugs could waltz thru that system with impunity. And, that system would
impede legitimate re-work which did . Those are the two indicators of TFUI

Short-term, the only fix is to augment our Ajax with acceptance tests, such
as Watir. Long term, assert_rjs could upgrade to start interpreting that
JavaScript instead of just matching it.

Tip: Much JavaScript looks a lot like Ruby. So if we tweaked it and then
trivially eval()-ed it, we could build a mock browser.

> BTW ... nice job on the amazon site ;-)

Dude, I have finally go to the point where writing about this stuff takes
longer than actually doing it!!

Phlip <-- NOT a blog!!!

New business?

Get new customers.

List your web site

in Yahoo! Search.

Y! Toolbar

Get it Free!

easy 1-click access

to your groups.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.