launchpad-dev team mailing list archive

[Jamu Kakar <jkakar@xxxxxxxx>]

Hi,

On Thu, Apr 14, 2011 at 3:47 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> On 11-04-13 08:16 PM, Ian Booth wrote:
>>> By "user-initiated action", do you you mean simulating mouse clicks?  I
>>> would have though you'd be testing callbacks rather than the actual UI.
>>
>> Yes, simulating mouse clicks. Think of it as black box testing.
>
> It don't do black-box unit tests, only black-box integration tests, so
> it seems a bit odd to me.
>> Often
>> the callbacks are not exposed and accessible to the test harness and you
>> want to see that all the internal wiring of handlers and callbacks is
>> correct and the DOM is properly updated (the output) in response to a
>> user action (the input), albeit short circuiting that aspect of the
>> interaction that occurs outside the component under test.
>
> But then again, this sounds a lot like an integration test.

Yes, you're right, the kind of test I'm describing is much more
integration-y than unit-y, but I find YUI Test-based tests for a
widget, for example, much easier to read, write and debug than the
equivalent Windmill or Selenium test.  If nothing else, the TDD cycle
is *much* faster.  Also, the tests I'm thinking of aren't exactly
integration tests in that they don't actually test widget X on page Y.
They place the widget on a blank HTML page, set the widget up, provide
any fake data sources the widget might need, and then use the widget
(by simulating button clicks, etc.) and make assertions about its
behaviour (often by way of testing changes made to the DOM).

You end up with a nice set of tests that are focused on the external
units of behaviour provided by the widget.  In many cases, getting the
widget into an expected state is much easier with this kind of test,
than with a Windmill or Selenium-based integration test, because you
don't have to think about how to twiddle your application Just So(tm)
to produce the condition you want to test.  Depending on the
complexity of the code you have, you may still want to go further and
test individual callback handlers, but knowing that the widget "works"
without having to integrate it and test it in an application setting
is quite nice.

Anyway, YMMV of course, but this method of testing widgets works very
well in Landscape.  If you're curious to see real examples, the
Javascript code and related tests are in
canonical/landscape/javascript in the Landscape tree.

Thanks,
J.