From: Ryan Platte <ryan.platte@...>
Date: 2007-01-05T01:45:10+09:00
Subject: Re: how to lex javascript for an assert_js system?

Phlip wrote:
> The goal is the target JS can flex easily - can reorder its Json, or
> change fuzzy details, or add new features - without breaking the tests.
> Ideally, only changes that break project requirements will break tests.
>
> Now suppose I want to write that assert_js() using less than seven billion
> lines of code.
>
> The first shortcut is to only parse code we expect. I'm aware that's
> generally against the general philosophy of parsing, but I'm trying to
> sell an application, not a JS parser. That's a private detail. I can
> accept, for example, only parsing the JS emitted by Rails's standard
> gizmos.

...

> Now the questions. Is there some...
>
>  ...way to severely beautify that implementation?

For Rails apps, by way of not testing the library('s JavaScript
output): stub out RJS's JavaScriptGenerator ('page' object)? That was
the first thing I thought when I heard about RJS. Surfing the code, it
looks quite possible using Mocha if it was desirable. I haven't thought
through all the ramifications. The OP includes testing the source page
-- maybe also some work on the APIs to link to and submit forms to Ajax
actions would permit those to be stubbed out as well.

Has someone already created such a beast? (Besides Google's GWT?)

--
Ryan Platte
Obtiva Training and Consulting
Agile, Ruby, Rails, Java Eclipse RCP
http://obtiva.com/