Here are some observations and suggestions resulting from my trying out Abbot:
about ScriptEditor
The menu Edit should also have an option "Delete", you can of course delete a step or sequence by calling Cut, but also having Delete would be convenient (also by pressing Del-key).
When I changed a value in the arguments textfield and called Test Run the change was ignored, it was also ignored after saving the xml-file. Only when I clicked into another textfield after entering the changes were they noticed.
After changing a script (Cut something out) I tried to open a new script, it was opened without requesting whether changes should be saved first.
When I save a script and enter an filename of an already existing script, the existing script is overwritten without security request.
When recording scripts for a complex GUI-Application recording was VERY slow (about 1 min for a typed text to appear in a textfield). The speed was significantly increased when I selected the "Thread"-option on the launch-command panel. Some documentation/explanation would be helpful.
---------
for documentation:
Tutorial 3 contains only the heading no real text.
You might include some info about the role of id at the top of the ComponentReference javadoc
and there (+ in a tutorium or reference) some examples.
If you have a JButton "go" and want to get a reference it you can call:
ComponentReference refBtn=new ComponentReference(null,JButton.class,null,"go");
btnGo=(JButton)refBtn.findInHierarchy(getFinder());
If the button's funtion is "go" but the actual text on the Button is localized into different languages, you can give the button a name in your application calling btnGo.setName("go"). In your test code you can then get a reference to the go-Button independent of the translated text that is shown by calling.
A ComponentReference isn't a true reference to a concrete single Component, but rather a ComponentDescription of a component for which a true reference is to be found.
Wouldn't it be more logical to call something like
maybe also allowing short forms
Component x=getFinder().findInHierarchy("Neuer Arbeitsbereich",JButton.class)
---
About the testers:
When I create a Tester object, would it make sense that a concrete ComponentTester (when created with getTester(component)stores the object that was used in the getTester(comp) method?
Then instead of having to call:
and wondering why they have to pass the button to the actionClick() method again when the tester was specifically created using it
users could simply call
ComponentTester btnTester=ComponentTester.getTester(newWorkareaBtn);
btnTester.actionClick()
----
I'd like as many parse-methods as possible to be static, as in Integer.parseInt
so no need to create an Object
new JTreeLocation().parse(..),
but just JTreeLocation.parse(..)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps the optimal lookup might be Finder.find(Matcher), where Matcher is an interface with
boolean match(Component c), so you can perform whatever tests you want to determine if the component matches. There is a findComponent(ComponentReference) on the ComponentFinder interface, but most of the smarts for matching is in ComponentReference itself, so there's not an ideal home for *all* the lookup logic.
Location parsing:
The parse operation *must* produce a ComponentLocation object. Who creates it is a wash.
ComponentTester creation:
getTester(Component) is actually meant for the scripting system, so that the objects can be cached for reuse. In manual tests you can simply call the ctor for the tester you want, e.g.
AbstractButtonTester t = new AbstractButtonTester. There was originally some idea of "you don't have to know what tester is available", but in reality, you want to so you can do more component-specific tests.
Please post to Bugs or RFE for specific issues; that makes it easier to track.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here are some observations and suggestions resulting from my trying out Abbot:
about ScriptEditor
The menu Edit should also have an option "Delete", you can of course delete a step or sequence by calling Cut, but also having Delete would be convenient (also by pressing Del-key).
When I changed a value in the arguments textfield and called Test Run the change was ignored, it was also ignored after saving the xml-file. Only when I clicked into another textfield after entering the changes were they noticed.
After changing a script (Cut something out) I tried to open a new script, it was opened without requesting whether changes should be saved first.
When I save a script and enter an filename of an already existing script, the existing script is overwritten without security request.
When recording scripts for a complex GUI-Application recording was VERY slow (about 1 min for a typed text to appear in a textfield). The speed was significantly increased when I selected the "Thread"-option on the launch-command panel. Some documentation/explanation would be helpful.
---------
for documentation:
Tutorial 3 contains only the heading no real text.
You might include some info about the role of id at the top of the ComponentReference javadoc
and there (+ in a tutorium or reference) some examples.
If you have a JButton "go" and want to get a reference it you can call:
ComponentReference refBtn=new ComponentReference(null,JButton.class,null,"go");
btnGo=(JButton)refBtn.findInHierarchy(getFinder());
If the button's funtion is "go" but the actual text on the Button is localized into different languages, you can give the button a name in your application calling btnGo.setName("go"). In your test code you can then get a reference to the go-Button independent of the translated text that is shown by calling.
ComponentReference refBtn=new ComponentReference(null,JButton.class,"go",null);
btnGo=(JButton)refBtn.findInHierarchy(getFinder());
---
I find the usual way to "extract" a component somewhat odd from an object-oriented point of view.
ComponentReference refNewWorkarea=new ComponentReference("Neuer Arbeitsbereich",JButton.class);
JButton newWorkareaBtn=(JButton)refNewWorkrea.findInHierarchy(getFinder());
A ComponentReference isn't a true reference to a concrete single Component, but rather a ComponentDescription of a component for which a true reference is to be found.
Wouldn't it be more logical to call something like
Component x=getFinder().findInHierarchy(new ComponentDescription("Neuer Arbeitsbereich",JButton.class))
maybe also allowing short forms
Component x=getFinder().findInHierarchy("Neuer Arbeitsbereich",JButton.class)
---
About the testers:
When I create a Tester object, would it make sense that a concrete ComponentTester (when created with getTester(component)stores the object that was used in the getTester(comp) method?
Then instead of having to call:
ComponentTester btnTest=ComponentTester.getTester(newWorkareaBtn);
btnTest.actionClick(newWorkareaBtn);
and wondering why they have to pass the button to the actionClick() method again when the tester was specifically created using it
users could simply call
ComponentTester btnTester=ComponentTester.getTester(newWorkareaBtn);
btnTester.actionClick()
----
I'd like as many parse-methods as possible to be static, as in Integer.parseInt
so no need to create an Object
new JTreeLocation().parse(..),
but just JTreeLocation.parse(..)
Finding components:
Perhaps the optimal lookup might be Finder.find(Matcher), where Matcher is an interface with
boolean match(Component c), so you can perform whatever tests you want to determine if the component matches. There is a findComponent(ComponentReference) on the ComponentFinder interface, but most of the smarts for matching is in ComponentReference itself, so there's not an ideal home for *all* the lookup logic.
Location parsing:
The parse operation *must* produce a ComponentLocation object. Who creates it is a wash.
ComponentTester creation:
getTester(Component) is actually meant for the scripting system, so that the objects can be cached for reuse. In manual tests you can simply call the ctor for the tester you want, e.g.
AbstractButtonTester t = new AbstractButtonTester. There was originally some idea of "you don't have to know what tester is available", but in reality, you want to so you can do more component-specific tests.
Please post to Bugs or RFE for specific issues; that makes it easier to track.