On 15/04/11 01:18, Jamu Kakar wrote: > Hi, > > On Thu, Apr 14, 2011 at 3:47 PM, Aaron Bentley <[email protected]> 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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
