The basic idea for a Generic Testdata Framework as an extension to the Robot Framework was initially described here . Well, things have been proceeding since then and there is an initial release available for download. This is more then reason enough for a follow-up blog post on this topic :).
The initial release can be downloaded from GitHub and is bundled with a simple sample application that demonstrates the usage of the framework. This initial release seems to be working fine, but it definitly lacks comprehensive handling of error situations and some further testing as well as some more features. More on the feature part is coming towards the end of this blog post.
Configuration & Directory Structure
The required configuration is explained in the Github-Wiki of this project . It should be noted that relative path information can be used to define the required directories and I would encourage you to do so (it is also done in the sample). This makes it much easier to work on the same project from different machines and/or with different persons. Thus the content of the Argument-File looks as follows:
ConfigurationDirectory = .\\sample\\config CsvDirectory = .\\sample\\csv TestsuiteDirectory = .\\sample\\testsuite
For the example I was re-using (part of) a sample testsuite I was using in some earlier blog post. This one is testing the Stack-implementation of Java. To demonstrate this framework it is as good or bad as almost any other example. But before we are taking a closer look at the configuration here a quick overview on the directory structure:
GTF Directory Structure
- We are starting from any root directory assuming the preferred definition of relative path information is used.
- In the config/metadata directory all metadata configuration files are stored, quite obviously.
- In the config/template directory the template files are stored.
- In the csv directory the testdata files are stored. Basically those are triggering to quite some extend which other files are expected.
- The resulting Testsuite-files are stored to the testsuite directory. It is the output directory so to say.
The names of the CSV-files define the names of the metadata-files that are searched (as described here ).
In the example the used CSV file has the following content:
Java;C++;PHP;Java Land;Instant;Socery;Land
This means we are having two testcases each using four arguments. It should be noted that for the GTF it does not matter which arguments are input-parameters to the test and which ones are resulting-parameters so to say. The corresponding configuration then looks as follows:
HeaderTemplateFileName = header.template FooterTemplateFileName = footer.template TestcaseTemplateFileName = testcase.template
ELEMENT_1 = 1
ELEMENT_2 = 2
ELEMENT_3 = 3
ELEMENT_RESULT = 4
Of course these definitions must be seen in the context of the template-file which will have %ELEMENT_1%, %ELEMENT_2%, %ELEMENT_3% and %ELEMENT_RESULT% expressions at the appropriate locations. The definition of the numbers on the other hand are matching the columns in the CSV-file. At least currently this means that the amount of columns in the CSV-files must match the amount of paramter-definitions in the metadata-file. (Later on there might be features that allow for additional columns in the CSV-file, e.g. for defining Robot Framework tags.)
Running the Generic Testdata Framework
After downloading and extracting the ZUP-file it should be possible to run the sample without any further changes. Just change to the directory into which you have extracted the ZIP and execute:
java -jar robot_gtf_v01a.jar sampleArguments.txt
It is assumed that you have Java installed on your machine. The example was created based on a Windows file system, thus you might have to adjust some configuration when running it on some Unix machine.
This will create a resulting Testsuite-file into the corresponding testsuite-directory.
Conclusion & Further Development
With the current release one can hopefully get an idea how this could be used. Still some more documentation would be nice for sure and better error handling as well. Furthermore I have already concrete ideas for quite some additional features.
- Tagging per CSV-File
- Tagging per Testcase
- Handling already existing Testcase Files
- Better error handling
Having the above list done for the next release would be quite nice.
Just in case you missed it: The initial version of the Generic Testdata Framework can be downloaded from here .
On the other hand I hope you find the required configuration and usage quite easy and understandable. As everything works on the command line it should be easy to add this as a step before executing the actual tests using the Robot Framework. For sure I will take a closer look on this interaction in one of the next posts on this topic.
Until then any feedback would be of course highly appreciated as all this is still in a very early phase and (bigger) changes can still be made more easily. Well, there is a new tool in town :-).
Robot Framework – Generic Testdata Framework
Part I: Robot Framework – Closing the Gap
Part II: Robot Framework Generic Testdata Framework – From the Idea to the initial Release
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.