| SWTBot at EclipseCon 2009 [message #14239] |
Thu, 15 January 2009 13:08  |
 Ketan Padegaonkar
Messages: 873
Registered: July 2009 |
Senior Member |
|
|
Hi,
I'm happy to announce that my tutorial
( https://www.eclipsecon.org/submissions/2009/view_talk.php?id =288) for
EclipseCon was accepted, and my employer is willing to sponsor my travel
to EclipseCon this year.
The tutorial is a two part tutorial on UI testing with SWTBot, which I
would be conducting, followed by eclipse profiling using TPTP (conducted
by some TPTP contributors)
Let me know if you're travelling to EclipseCon and would like to help
out with the tutorial.
Here's an outline of the SWTBot tutorial (2 hours). Note that the
intended audience are not only developers, but also quality analysts.
I'm looking for any inputs on what what the community thinks about the
outline. Feel free to reply on this thread or over private email to me.
The outline of the tutorial:
For beginners:
Types of testing:
- unit testing - for quick feedback - red/green/refactor - primarily
used by developers
- functional testing - long running - to test 'functionality'
Understanding of SWT:
- Not everyone can understand SWT threading models
- Too many things to keep track of when testing SWT controls - UI
thread, state of controls, etc
Challenges of writing testable code:
- good use of MVC
- minimal code in button click events
- delegate as much 'non-ui' behavior into classes that are independent of UI
There's always something more to test:
- writing end-to-end tests that go through complete application flows
- easier to do this at a UI level
- these tests cannot be written as 'unit-tests'
Challenges in writing end-to-end tests:
- finding controls - how do you refer to a textbox with label 'project name'
- what about controls with the same text ? for e.g. two 'edit' buttons
in a screen
- what do you do about controls that move around in the UI ?
Multi threaded applications:
- doing most of the heavy lifting in the background, while updating the
UI at regular intervals
- there's no guarantees about when the background work finishes - how do
tests deal with indeterminate behavior of background jobs
For the more advanced users:
Given all the issues above, how do you ensure that your tests are
scalable, and maintainable over time:
- some common UI testing patterns
( http://ketan.padegaonkar.name/2008/06/21/reusing-functional- tests-part-1.html)
- objects that interact with screens and expose screen behavior and not
controls
- refactoring 'test-scripts' to ensure that they follow this pattern
All the examples will use SWTBot to write expressive and intent
revealing tests.
-- Ketan
|
|
|
| Re: SWTBot at EclipseCon 2009 [message #15123 is a reply to message #14239] |
Thu, 15 January 2009 17:54  |
David Green
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Ketan,
Congratulations, I look forward to meeting you at EclipseCon! Your
tutorial sounds great.
David
Ketan Padegaonkar wrote:
> Hi,
>
> I'm happy to announce that my tutorial
> ( https://www.eclipsecon.org/submissions/2009/view_talk.php?id =288) for
> EclipseCon was accepted, and my employer is willing to sponsor my travel
> to EclipseCon this year.
>
> The tutorial is a two part tutorial on UI testing with SWTBot, which I
> would be conducting, followed by eclipse profiling using TPTP (conducted
> by some TPTP contributors)
>
> Let me know if you're travelling to EclipseCon and would like to help
> out with the tutorial.
>
> Here's an outline of the SWTBot tutorial (2 hours). Note that the
> intended audience are not only developers, but also quality analysts.
> I'm looking for any inputs on what what the community thinks about the
> outline. Feel free to reply on this thread or over private email to me.
>
> The outline of the tutorial:
>
> For beginners:
>
> Types of testing:
> - unit testing - for quick feedback - red/green/refactor - primarily
> used by developers
> - functional testing - long running - to test 'functionality'
>
> Understanding of SWT:
> - Not everyone can understand SWT threading models
> - Too many things to keep track of when testing SWT controls - UI
> thread, state of controls, etc
>
> Challenges of writing testable code:
> - good use of MVC
> - minimal code in button click events
> - delegate as much 'non-ui' behavior into classes that are independent
> of UI
>
> There's always something more to test:
> - writing end-to-end tests that go through complete application flows
> - easier to do this at a UI level
> - these tests cannot be written as 'unit-tests'
>
> Challenges in writing end-to-end tests:
> - finding controls - how do you refer to a textbox with label 'project
> name'
> - what about controls with the same text ? for e.g. two 'edit' buttons
> in a screen
> - what do you do about controls that move around in the UI ?
>
> Multi threaded applications:
> - doing most of the heavy lifting in the background, while updating the
> UI at regular intervals
> - there's no guarantees about when the background work finishes - how do
> tests deal with indeterminate behavior of background jobs
>
> For the more advanced users:
>
> Given all the issues above, how do you ensure that your tests are
> scalable, and maintainable over time:
> - some common UI testing patterns
> ( http://ketan.padegaonkar.name/2008/06/21/reusing-functional- tests-part-1.html)
>
> - objects that interact with screens and expose screen behavior and not
> controls
> - refactoring 'test-scripts' to ensure that they follow this pattern
>
> All the examples will use SWTBot to write expressive and intent
> revealing tests.
>
> -- Ketan
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.02903 seconds
] 
Search
Help
Register
Login
Home
