I understand that you have not replied to the previous message and I would not like to insist on issues that may require great effort to implement or that simply are not within the strategy of the Generic Fixture, but I have another suggestion that I believe can bring huge advantages.

Would you consider enabling the DSL to construct ‘groups of actions’? DSL defined ‘multi-commands’, which would be just like any other, however these would execute a series of calls instead of just one.

The way to implement it and the actual syntax could take many forms, here is a (silly) example:

!| DSL Adapter |
| open browser, go to url | % | and fetch the title | StartMultiCommand | {1} |
| user starts the browser | start | |
| user opens the URL | % | open | {1} |
| retValue=page has the title | getTitle | |
| EndMultiCommand | retValue= |

Notice that though one can pass many variables to it, it only returns one result (retValue=)

This could be invoked by the following:

!| Generic Fixture | selenium= |
| open browser, go to url | http://www.google.com | and fetch the title | | Google |

and if the previous post is also accepted, then the first line (defining selenium as the object) can be hidden in the DSL definitions of the individual commands and hence leaving for the test narrative only the second line:

| open browser, go to url | http://www.google.com | and fetch the title | | Google |

Obviously much better examples can be easily thought of, but I think that the benefit is more than obvious: achieving a light-weight, natural-language, executable test narrative that can be easily implemented and maintained, practically, without any coding!

I do not know if this is feasible using Generic Fixture, nor whether you share the opinion of its importance and potential. I would love to hear your (or anyone else’s) opinion though.

Thanks in advance,
Aristotelis.

Thank you for your reply, and no it was not too long, it was all needed for me to understand.

I see your dilemma (‘to flow or not to flow’…) and I have an idea that may be of interest to you.

What if you define in the DSL, for each command/lemma, the fixture that it belongs to?

This way each lemma would be uniquely identified and the natural language on the test script would not be harmed.

Exampe:

| user opens the URL | % | sel= | open | {1} |

Alternatively this could be also done in groups, example:

!| DSL Adapter | sel= |
| user starts the browser | start | |
| user opens the URL | % | open | {1} |

!| DSL Adapter | myClass= |
| friendly name | % | and | %| myFriendlyFunc | {1},{2} |
| other name | % | and | %| myOhterFunc | {1},{2} |

I do not know whether these are implementable, but if they are I’d think they would be of great interest to many.

thanks,
Aristotelis.

I have uploaded my DSL definition for Selenium API in this Blog post. This doesn’t cover Selenium API completely but it has been sufficient for my needs. Please feel free to add whatever you find missing in this DSL definition set.

Now about your suggestion about avoiding use of:
!| Generic Fixture | selenium= |

You may know that all “flow type” fixtures such as DoFixture have this capability where you specify name of your DoFixture only once on a page. I have actually thought about it many times on similar lines but stopped short of modifying “Generic Fixture” code to provide this ability. Let me try to explain why.

Underlying Fixture framework expects the name of the Java Class in the first cell of the first row of the table. That Java class is instantiated by Fitnesse framework and becomes system under test (SUT). Rest of the code in the table is interpreted by that class only. But “Generic Fixture” even though acts as SUT for underlying framework is actually is a broker that executed methods of the class name you provide to GenericFixture (for example com.thoughtworks.selenium.DefaultSelenium or as a variable selenium=

So actual SUT is Selenium not GenericFixture. At present GenericFixture supports you to change this real SUT multiple times in different table on same page for complex testing scripts.

If I make GenericFixture a “flow type” fixture then you will be able to execute methods of ONLY one class on a page such as Selenium. But in most of the real life test scripts using GenericFixture, testers use various other Java classes such as String or Decimal or BeanShell to get better assertion support. Many of my own test scripts involve hitting a database using a SQL query after posting some data from web form to verify that data has been stored in database correctly.

Sorry for the long answer but I hope you got my point. But I must say you have raised a veery valid issue. And now I have started thinking that may be give this option to end user if he/she wants “flow type” behavior or not on a SetUp page or at the top of the page. I will start researching this option as soon as I get some free time.

cheers,
Anubhava

Thanks for your reply and great attitude.

I have one more question that may be of interest to more people.

Considering that the main advantage and added value is the ‘almost natural language’ in which the tests are written,

we’d like to know if it is possible to omit the
!| Generic Fixture | selenium= |
from the beginning of each table.

Is there a way to make it the ‘default’ or just write it once at the beginning of the document?

Thanks again.

Thanks for your great feedback. I will upload my selenium DSL definition that I use for my own testing very soon.

Thanks,
Anubhava

Great work on the generic fixture!

Does anyone know if there is an already created DSL definition of many (or all) of the Selenium commands?

We have been exploring tools such as WebTest, Fitnium and now we have discovered the Generic Fixture!

We are interested in using it in conjunction with Selenium RC.
We followed your instructions and we even mapped a few Selenium commands to our DSL which was great!

We think that such a pre-made list would be very helpful and a great kick-starter as well for most of the cases.

Thanks and keep up the great work!

as soon as i looked at Fitnesse i disliked the idea of every test potentially requiring code to be written.
If we have testers writing code who tests the testers tests?
If we let the developers write the tests then where is our tester independence?

After few small problems (thank you sourceforge) i have your genericfixture and the DSL adapter working, and its exactly what i wanted to accomplish, thank you anubhava.

Stuart.

Jason Rakowski