Re: Testing Javascript

On 07:34 am, [email protected] wrote:
>On Thu, Jun 26, 2008 at 5:13 PM,  <[email protected]> wrote:
>>On 12:28 am, [email protected] wrote:

>>It's perfectly fast; we've never had a problem with speed, AFAIK.

>I seem to remember loading testing pages in my browser that took ages =

>to run.

Ah yes.  That would be 'nit'.  We don't really write nits much any more, =

as they're slow, they don't integrate with the main test run, and =

(despite running in an actual browser) they don't provide much more in =

the way of useful integration testing, since they don't work over =

multiple themes, have a realistic frame page, or include any CSS.
>Right. Any fake DOM would have to be tested itself with interface
>compliance tests that run it and the DOMs of your supported browsers.
>Any environment that let you do that easily would also let you just
>write the tests without needing a fake DOM :)

Indeed.  Ideally we'd do what you say here, but I'd be happy just to =

have a fake DOM that had been derived from experimentally determined and =

specifically documented behaviors of specific, supported browser =

versions.  Verifying it would be nice, but Firefox 2 isn't going to =

change.
>I think you've focused mostly on the unit testing stuff I worked on
>ages back. ISTR you have any integration tests for JS stuff that talk
>to the server? (I definitely recall big testing pages that took ages
>to load). Do you still do that? How does it work?

There are still nits for nevow itself (athena, really), although they =

don't integrate with the buildbot and I haven't worked on that code in a =

while.  Technically there are nits for a bunch of Mantissa and Quotient =

functionality, but all new code being written in those areas has JS unit =

tests instead.  It may be getting to be time to delete the ones that are =

still in the tree.

One of the things preventing us from deleting the existing nits is that =

we don't have a mock transport that would allow JS code running in a =

unit test to talk to Python; nits allow you to communicate back and =

forth.  My plan here is to eventually replace subunit with a richer, =

two-way communication layer that allows Python to send JavaScript =

expressions as fake athena calls and parse the output that they =

generate.