Jubula test case/test steps data model [message #906858] |
Sun, 02 September 2012 19:55 |
Eclipse User |
|
|
|
Hi all,
I'm new to Jubula (not to testing, though) and I have a question regarding
the internal data model of test cases/test steps/test suits of Jubula. How
are these internally represented? In the screencasts, they look pretty much
like EMF models?!
Why do I ask?
We would like to generate test suits from external sources, which are
actually represented as an Ecore DSL. Theoretically, this should work pretty
well, but I've to little knowledge about Jubula's internals for now. I just
flicked quickly through the binaries, but I did not find any EMF model,
though.
So, is it possible to generate those test suits/test cases/test steps
instead of creating them via drag'n'drop?
Any hint is appreciated.
Thanks in advance,
Florian
|
|
|
Re: Jubula test case/test steps data model [message #907051 is a reply to message #906858] |
Mon, 03 September 2012 08:04 |
|
Hi Florian,
Jubula uses JPA as its persistence layer, especially EclipseLink. We are looking into migrating to EMF, but it is a really long term thing.
To generate TCs etc. you have a few options (which all involves looking at the source, look at the developer info for hints how to get it).
The easiest way is to generate an XML archive. The XSD is in the org.eclipse.jubula.client.archive project in model/archiveModel.xsd. To get some of the semantic it would be helpful to look at the XmlImporter/XmlExporter classes in the same project to see how this is supposed to work.
When you look at the XmlImporter class you will see lots of calls to POMaker and NodeMaker class utilities. These are the classes to create the entities of the data model. Together with a few calls to JPA you can create and store models. Again, it is fairly obvious in the code. Please don't try to create objects without going through the xxMaker classes because that might fail with every new version of Jubula. The archive and xxMaker interfaces have been stable for the last few releases and there are no plans to change them in the near future.
- Achim
|
|
|
Re: Jubula test case/test steps data model [message #909241 is a reply to message #907051] |
Thu, 06 September 2012 19:48 |
Eclipse User |
|
|
|
Hi Achim,
thanks for your answer. Have you ever considered to use the concets provided
by UML Testing Profile? From what I've seen so far in the screencasts those
keyword libraries and scripts can be really conveniently mapped to the UML
Testing Profile.
Marc-Florian
"Achim Loerke" schrieb im Newsbeitrag news:k21obc$h3l$1@xxxxxxxxe.org...
Hi Florian,
Jubula uses JPA as its persistence layer, especially EclipseLink. We are
looking into migrating to EMF, but it is a really long term thing.
To generate TCs etc. you have a few options (which all involves looking at
the source, look at http://www.eclipse.org/jubula/developers.php for hints
how to get it).
The easiest way is to generate an XML archive. The XSD is in the
org.eclipse.jubula.client.archive project in model/archiveModel.xsd. To get
some of the semantic it would be helpful to look at the
XmlImporter/XmlExporter classes in the same project to see how this is
supposed to work.
When you look at the XmlImporter class you will see lots of calls to POMaker
and NodeMaker class utilities. These are the classes to create the entities
of the data model. Together with a few calls to JPA you can create and store
models. Again, it is fairly obvious in the code. Please don't try to create
objects without going through the xxMaker classes because that might fail
with every new version of Jubula. The archive and xxMaker interfaces have
been stable for the last few releases and there are no plans to change them
in the near future.
- Achim
|
|
|
|
|
|
Re: Jubula test case/test steps data model [message #1015838 is a reply to message #1015834] |
Sun, 03 March 2013 15:10 |
|
Hi Jeremie,
the org.eclipse.jubula project should only be on the CDO branch of the repository. It is part of a proof of concept which has been stopped due to missing time. The core team will look into a lot of options to change the persistence layer during the annually refactoring cycle. We might decide to go for CDO or a completely different route.
- Achim
|
|
|
|
Powered by
FUDForum. Page generated in 0.02573 seconds