Open GoogleCodeExporter opened 9 years ago
Hi Michael,
I really like the idea! I'm afraid I don't completely understand what this task
involves :)
An example will help me understand it better :D
-Alex
Original comment by Alex.Rui...@gmail.com
on 23 Oct 2008 at 1:46
I mean an abstraction layer customers and domain experts can work with --
something
equal to "Fit" but perhaps even more sophisticated. Look here:
http://devoxx.com/display/JV08/Agile+Testing+of+Java+Rich+Clients%2C+with+Fit%2C
+FEST+and+TestNG
Looking forward to collaborating more on this topic..
Michael
Original comment by michael....@googlemail.com
on 26 Oct 2008 at 11:38
That is totally awesome news! Many thanks for including FEST in your talk! We
are
honored! :)
Yes! I like the idea to have something like Fit. I used Fit/Fitnesse a couple of
years ago and it worked. But, if something went wrong, it was a real PITA to
debug.
It was time consuming to figure out if the problem was in our code or in the
custom
Fit fixtures. I think that, together, we can come with something better! :)
Many thanks!
Cheers,
-Alex
Original comment by Alex.Rui...@gmail.com
on 26 Oct 2008 at 4:10
wonderful, so let's analyse what would make sense and what is possible. Looking
forward being a contributor on this. Perhaps we can build up a companion
framework
which serves as a domain based, easy to use abstraction ..
Original comment by michael....@googlemail.com
on 26 Oct 2008 at 4:53
It sounds like a good start point! We can either create it as a separate
project or
as a module in the FEST project...whatever makes more sense1
I'm very excited about this idea! :)
-Alex
Original comment by Alex.Rui...@gmail.com
on 27 Oct 2008 at 5:21
Set the module as a label, instead of being part of the title.
Original comment by Alex.Rui...@gmail.com
on 1 Dec 2008 at 5:10
Hi I am already using a GUI Test DSL in our project (Warehouse management
system)
using Groovy, see below an example (the DSL is written in german, sorry ;-)
testcase
(and setup):
@Before
void setUp() {
cobra = Cobra.login_as("user", "secret")
cobra.warehouse = Cobra.LOEHNE
}
@Test
void testSonstigeContainerErfassenUndAuslageren() {
cobra.sonstige_container().
erfasse("123456").
fuer([
[Artikel: "11252", Menge: "1"],
[Artikel: "11252", Größe: "40", Menge: "1"]
]).
abschliessen()
def win = cobra.auslagerungsauftrag().
erzeuge("123123").
fuer([
[Artikel: "11252", Menge: "1"],
[Artikel: "11252", Größe: "40", Menge: "1"]
]).
abschliessen()
def my_vorgang = win.value_of.vorgang
cobra.auslagerung().
ausloesen().
fuer([
[Vorgang: my_vorgang]
]).
abschliessen("Warenausgang")
cobra.vorgang().
fuer(my_vorgang).
abschliessen()
}
This testcase is build on a couple of DSL classes which relate to a
screen/frame.
Each such class has business methods to deal with business actions. As you can
see
above the scenario is composed of 4 steps for which each step consists of at
least 3
substeps. Below you see an example DSL class:
public class Vorgang extends GFrameFixture{
Vorgang(){
super("Vorgang abschließen.*", true)
set_fixtures (
txt_vorgang : {textbox(label:"Vorgang:")},
txt_datum : {textbox(label:"Datum:")}
)
}
def fuer(vorgang) {
txt_vorgang.enterText(vorgang)
pressAndReleaseKey(key_enter)
txt_datum.requireText(String.format('%td.%<tm.%<tY', new Date()))
return this
}
def abschliessen() {
select_menu "Aktion", "Vorgang abschließen"
select_menu "Datei", "Schließen"
return this
}
}
I have written a small Groovy framework based on FEST to leverage my DSL
classes. See
the constructor, this relates the current visible frame with provided title
(using a
regular expression). Next it defines which gui components will be properties of
this
class like 'txt_vorgang' is a textbox. I have extended the textbox(...)
functionality
to deal with maps to match on jtext* properties. Also I have added the 'label'
feature to identify a textbox based on a label nearby which matches a regular
expression (Since in my project no .name properties are being set :-).
There are more features like dynamically add or selecting rows on a table using
lists
and maps....
Original comment by Michel.L...@gmail.com
on 2 Dec 2008 at 9:19
Hi Michel,
Very nice indeed!! The DSL looks really cool!! Would you be interested in
contributing your Groovy DSL work to the project? :)
I also like the idea of identifying a component by its associated label. I
think it
would be a good idea to add a Matcher in FEST that does exactly that! I'll file
an
enhancement request.
Thanks,
-Alex
Original comment by Alex.Rui...@gmail.com
on 2 Dec 2008 at 1:28
[deleted comment]
Issue migrated to http://kenai.com/jira/browse/FEST-47
Original comment by Alex.Rui...@gmail.com
on 15 Feb 2009 at 5:08
Issue migrated to http://jira.codehaus.org/browse/FEST-51
Original comment by Alex.Rui...@gmail.com
on 5 Mar 2009 at 8:08
Original issue reported on code.google.com by
michael....@googlemail.com
on 23 Oct 2008 at 11:08