Welcome to our community! I hope Abbot for SWT
https://w3.opensource.ibm.com/projects/abbotforswt/can help you and can be helped by you. Below, I discuss, and would appreciate your feedback regarding,
I would also appreciate your suggestions regarding how to improve the project (e.g. this page!)
To get the code, either
check out from CVS: see our CVS page for details. (Note that contributing to abbotforswt on IIOSB requires the "ext" protocol under ssh2.)
The following are some quick howto's, intended to help you write testcases for different kinds of code. Note that they are likely to be unpolished.
Abbot is an OSS project
http://sourceforge.net/projects/abbotenabling you to
It also includes a recorder, enabling more rapid development of testcases and suites, as well as basic blackbox-style testing. Abbot builds its functionality atop Sun's J2SE-standard java.awt.Robot (aka j.a.R).
"Abbot for SWT" (hereafter "abbotforswt") is an Eclipse plugin currently in IIOSB @
https://w3.opensource.ibm.com/projects/abbotforswt/which seeks to extend Abbot ... for SWT (but you guessed :-) We do this to provide SWT UI developers (e.g. WebSphere Studio plugin developers) with a "code-centric" way to automate their testing (more below). (Note that our intention is not to release Abbot or abbotforswt in any IBM product, only to use it to improve the quality and time-to-market of the products on which SWT UI developers labor.)
abbotforswt extends 4 aspects/levels of Abbot to provide
an SWT-enabled equivalent for j.a.R
j.a.R provides low-level utility for many purposes, and is used by many AWT/Swing automation and testing products. Our (provisionally named) com.ibm.swt.Robot (aka our "base Robot"), which hasa j.a.R, should have similarly broad utility for SWT UIs. Furthermore, since its public interface is very similar to that of j.a.R
our Robot Sun's Robot
--------- -----------
Robot() Robot()
Robot(Display) Robot(GraphicsDevice)
createScreenCapture(Rectangle) createScreenCapture(Rectangle)
delay(int) delay(int)
getAutoDelay() getAutoDelay()
getDisplay()
getPixelColor(int, int) getPixelColor(int, int)
isAutoWaitForIdle() isAutoWaitForIdle()
keyPress(int) keyPress(int)
keyRelease(int) keyRelease(int)
mouseMove(int, int) mouseMove(int, int)
mousePress(int) mousePress(int)
mouseRelease(int) mouseRelease(int)
setAutoDelay(int) setAutoDelay(int)
setAutoWaitForIdle(boolean) setAutoWaitForIdle(boolean)
setDisplay(Display)
toString() toString()
waitForIdle() waitForIdle()
waitForIdle(Display)
it should allow "snap-in" SWT compatibility for tools built on j.a.R.
an SWT-enabled equivalent for Abbot's Robot. "Abbot" is short for "A Better 'Bot"; Abbot's Robot provides higher-level semantics for testcase creation than does j.a.R. E.g. one's testcase can create a AWT/Swing Component and then call mousePress(Component) or drag(...) and then drop(...) it. (See
http://abbot.sourceforge.net/doc/api/abbot/tester/Robot.html
for its API.) Our (provisionally named) com.ibm.abbot.tester.swt.Robot provides the same functionality for SWT Widget's (at least, those that extend Control--more below).
"Testers" that provide equivalent functionality wrt SWT Widget's as Abbot's current testers do for AWT/Swing Component's. Testers provides a yet-higher level of abstraction/ease of use. E.g., having created a JComboBox, one can get its items with JComboBoxTester.getContents(JComboBox), in addition to being able to call all the abbot.tester.Robot methods (since Abbot's testers extend its Robot). In this case, since the SWT's Combo ~= JComboBox, abbotforswt's ComboTester ~= Abbot's JComboBoxTester.
higher-level functionality. In addition to the "in-source" functionality described above (and defined below), Abbot provides a blackbox-style script recorder and editor (Costello), as well as support for running scripts as JUnit testcases. We are currently working on providing equivalent functionality for SWT, e.g. by providing finders and recorders for Widget's corresponding to Abbot's finders and recorders for Component's.
abbotforswt itself seeks to provide
Eclipse-specific packaging. We intend to "gift-wrap" all of the above by providing an Eclipse plugin to access/enable all the PDE goodness (including, if possible, update management) to improve ease of adoption for our target market.
Our current target market is, frankly, people like me: developers of SWT UIs who want to do TFD of new UIs, or automated regression testing (ART) of existing UIs, with maximal standards-compliance and minimal non-code interaction. (Note that, internally, there are lots of people who, like me, are WebSphere Studio UI developers who are required to do their own FVT--a task which is singularly tedious, neurotoxic, and error-prone. Note also that we do not intend to release Abbot in any IBM product--we just want to use it to do ART and, ultimately, TFD, of the SWT UIs that constitute our "real jobs.")
Abbot and abbotforswt appeal to this market because they enable "in-source testing." These tools allows one to develop tests in the same conceptual space (e.g. in the same workbench, manipulable with the same tools, storable in the same repository, *as part of the same development process*) as one's source. (Although, strictly speaking, one will usually package non- and buildworthy code separately, I will use my term "in-source" in preference to the more frequently used, but unfortunately multiply-defined, term "whitebox." I will continue to use the more-well-defined, traditional term "blackbox," but keep in mind that blackbox testing is necessarily "out-of-source." Explanation upon request.)
The advantages of in-source testing include greater coder-friendliness and robustness under code change, and are obtained by
Note that our tool is thus *not* designed to compete with blackbox/ out-of-source solutions, such as XDE Tester. Costello's featureset is rudimentary compared with Rational's tools, and is in any case inherently Java-only (unlike the Rational Robot family and descendents). OTOH, it is difficult to see how a blackbox tool could be used for TFD, and it is reasonable to expect that in-source ART tools will be far more stable under refactoring, and more substantial code change, than blackbox tools, for the forseeable future. (YMMV.)
To serve our target market, and turn it into a self-sustaining community, we have sought to release rapidly (i.e. "make it available") and to release so as to enable user-friendly install (i.e. "one-stop shopping"). Longterm, the best way to do this seems to be to contribute our code to Abbot, since we extend, and require, Abbot. If we contribute our stuff on Abbot, users can get everything in one place. This is agreeable to the Abbot maintainer (Timothy Wall), who has been very supportive.
A SWTized j.a.R (i.e. an SWT-enabled equivalent of j.a.R, such as our base Robot), and indeed much of the test/automation functionality abbotforswt seeks to provide, was originally requested by an i-Series coder in May _02_. IMHO it "fills a hole" in SWT vis-à-vis AWT/Swing by providing it with matching functionality. We have proven that our base Robot can automate SWT UIs: we have ported the CelsiusConverter UI and Abbot-based testcases done for a recent JDJ article
http://www.sys-con.com/java/articleprint.cfm?id=1940to SWT and abbotforswt, and our testcases run from either one's own development workbench, using Run As>JUnit Test, or from a launched WebSphere Studio target, using WS's internal Test Collector. This would seem to imply that a base Robot would be useful for Eclipse automation, such as the following Eclipse 3.0 plan items:
Since Abbot is now CPL, and our base Robot is "cut'n'paste clean" and (like j.a.R) free of Abbot references, it could *probably* (IANAL!) be donated to Eclipse (e.g. SWT or JFace/platform-ui) without contamination, and without complicating abbotforswt install. (If in Eclipse, it would not require a separate install.)
I can also see how abbotforswt could be useful in achieving some other Eclipse 3.0 plan items:
However abbotforswt is fundamentally a test tool, so I can also see how it would fit into Hyades.
But wherever abbotforswt is eventually housed, it, and more importantly its target community of Eclipse and WebSphere Studio plugin developers, and therefore E/WS as collections of plugins, could benefit from the assistance of potential stakeholders such as yourself. abbotforswt would likely benefit from help from groups such as
SWT. abbotforswt would benefit from both the active and passive assistance of the SWT team:
actively: We need help finding some non-Control Widget's, and want a more general finding API. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=38436passively: While we strive to remain within decent limits, we will likely remain somewhat intimate with the Widget's we seek to automate. We would therefore appreciate a decent consideration, and not to be broken by SWT changes either gratuitously or ignorantly.
JFace/platform-ui. We have only begun to automate more complex and workbench-aware UIs (namely one of my wizards). Being the realistic/ pessimistic sort, I suspect difficulty will be encountered, since the workbench and the widgets are still all-too-intertwined (though progress is of course being made in this regard).
PDE. Most of our target market codes for plugins, so our tool should play well with PDE tools, esp those relating to launching and testing, notably o.e.pde.junit.
Hyades. Our tool can help coders create tests, but not to determine their coverage, or, if used for profiling, to record performance data. The more easily and usably our tool fits into a larger test framework, the happier our target market (and, more importantly, their customers) will be.
How can we help you? How can you help us? Please let us know, preferably via our forums:
Contribute or Request Feature: Got a suggestion? Want to help? Wanna become a developer? Please post here.
Problems: Need help? Or think you've found a bug? Please post here.
and feel free to subscribe to our
for major news (e.g. new releases, or externalization)
Of course our CVS is open for reading to registered IIOSB users. Note that it requires you to use ext and ssh2.
If you would like to help us develop or document, please send me an email!