Hi Rob,
> On the agile-testing list, I've been gathering info WRT acceptance
> tests for this and comparing WatiR, WatiN, Selenium, etc...
>
> So now I've noticed that our WatiN tests are very slow. (We have some
> NUnitAsp tests too which are worse.) We have 100s+ tests in FitNesse
> that take about 80s to run. And <10 in WatiN that take about 80s to
> run.
Yes, UI tests are very slow, whether it's web-based or GUI. That's one
of the big problems with them. Sometimes you're forced to decide on
timeout periods, and so have to balance speed against spurious fails.
The other problem is that the UI tests are verbose and tend to be
fragile under changes to the UI (I'm working on solving this problem).
>
> So I'm theorizing that Fit tests are really going to be the stronger
> set. It'll be 1 layer down, but as long as we do some sort of MVC/MVP
> or simple command pattern, we only won't be testing the client-side
> validation. I'm debating whether or not those tests are even worth
> writing? Especially if for example, we submit some form and the server
> side validates fields as well.
I recommend using Fit for testing below the UI layer. Then have some
UI-based tests that verify end-to-end behavior, so that pages are
'wired" together correctly, etc.

If the UI tests are too slow, you can run a two-stage build process,
with fast feedback from Fit storytests. I've also had success with
running lots of Selenium tests in parallel.
>
> Furthermore, for reuse of the validation logic, I'm leaning towards
> less JavaScript in the page for AJAX calls that get their results from
> the server.
That's a tricky one, as Fit is only good for validating logic on the
server. I'd use Javascript unit tests for testing the AJAX and
validation logic in Javascript. And, again, have some UI tests to check
end-to-end.

Cheers, Rick

PS, if GWT was used, the Java code intended for translation to
Javascript could be tested with Fit
>
> Thoughts?
> Comments?
>
> .rob.