launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

On 15/04/11 01:18, Jamu Kakar wrote:
> 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).
> 


+1
This is also how I have started to write my yui tests. To me, they are
not integration tests since the rest of the system is stubbed out. I
guess module tests is the more correct terminology and what I should
have used in my first reply above.

> 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.
>

+1 again
Windmill tests often require a fair bit of application twiddling and
data model set up that really adds no value to what is being tested and
is just another potential point of failure.


> 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.
>

Great. Thanks for sharing.