Re: [abbot - Developers] Automated testing
Timothy Wall <twall <at> users.sf.net>
2009-07-08 13:12:41 GMT
On Jul 4, 2009, at 8:33 AM, SourceForge.net wrote:
>
> Read and respond to this message at:
> https://sourceforge.net/forum/message.php?msg_id=7479692
> By: eamonnmag
>
> I've looked at this software, but i believe it to be heavy,
> considering the
> fact that i have >50k lines of GUI code in an application. Testing
> every possible
> combination of events in an event driven environment would be pretty
> difficult
> using this framework.
>
> I was wondering who of you would be interested in developing an
> annotation driven
> mechanism for testing GUIs in a brute force sort of approach. I.e.,
> we use robots
> to browse through the entire GUI space -> encompassing multiple
> forms, events,
> and so forth and using annotations to provide test data to things
> such as text
> fields, combo boxes, and so forth where appropriate.
>
> I think this could be a very possible system to code up, but i have
> only really
> just thought a bit about it, had a look at what's already out there
> (only really
> this framework) and thought about what could be an improvement in
> such a complex
> testing environment.
>
> Anyone interested, or do you believe this to be an unattainable goal?
I don't think Combinatorial tests will give you much payback, given
that you won't have time to run them all and the number of *useful*
combinations is a miniscule set of the *available* combinations.
Fundamentally, you have to put intelligence into your tests. Ideally,
you could write a single, detailed description of user actions in one
place and have that used as the basis for both constructing the UI
*and* running a test against the UI. But that requires your UI
construction set has to include incorporation of that description into
the building of the UI, and the UI itself needs to expose sufficient
API for the test harness to perform its tests.
Swing is rather poorly constructed in that respect. It's non-trivial
to programmatically exercise the same code paths that are followed
when a user drives the UI. I found it most effective to isolate UI
component testing into code-driven Abbot tests, which would cover all
aspects of the component functionality. I'd then try for reasonable
coverage driving the integrated UI more programmatically, avoiding
event-driven tests to the extent possible, since event driven testing
is both slower and more error prone.
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
RSS Feed