Same AUT Definition for multiple Projects / etc.https://www.eclipse.org/forums/index.php/mv/msg/452361/1006424/#msg_1006424
Hopefully my slightly provocative Question in $topic Description will not trigger any negative outcome as it was rather "tongue in cheek"ishly formulated.

My "learning path" concerning this question which brought me here was kind of the following (all concerning eclipse RCP AsUT):

a) Find out about Jubula and realize that it is a great tool
b) Find out about getting started and running some Tests
c) Find out about generalizing some functionality
d) Find out about reusability of Test-Suites/-Cases
e) Find out about the needed restructuring of my organisation of Test-Projects/-Suites/-Cases so that i can build some kind of higher level Development-Testsuite with bleeding edge changes and a higher level Deliverable-Testsuite with a more stable AUT as the basis which handpicks different reusable Test-Cases. (Which btw was a result of reading this forum and finding out about the Tips alex gave in some posts some weeks/months ago which were really helpful )
f) Find out that fresh created Projects needed for e) are empty and need a new AUT configuration

Soo ... after this rather long explanation ... now i am at the point realizing that propably i need to create the same AsUT-Definitions for each and every Project which is needed for the e) part mentioned earlier.

Which leads me to my question: Is it possible to create a blank project and kind of "inject" an existing AUT-Definition into it via import/export or any other way?

Thank you for reading this far!
Dan

//edit:
As a followup question (or, more likely questionS):
- what happens if i copypaste the AUT-Definition from xml-export to xml-export?
- is it ok if i just copypaste the <objectMapping>-Tags from inside the aut-definitions from export to export?

I am playing around with it currently and was able to tame a "objectmapping is incomplete in your AUT"-like errormessage via copypasting the <objectMapping>-Tags.

It works but i feel a little dirty now ]]>Dan H.2013-01-31T10:32:10-00:00Re: Same AUT Definition for multiple Projects / etc.https://www.eclipse.org/forums/index.php/mv/msg/452361/1006607/#msg_1006607
I'd certainly not recommend playing around in xml - it may work, but there's no guarantee that it won't do something nasty (and, in the next version, the xml files won't be as readable either).

There's no concept for sharing AUTs or object mapping across projects - but I'm not 100% sure that you need that. It sound like you may need a structure that looks like this:

---------
Test Cases:
All necessary Test Cases for the project (possible separated into a reusable "library" project and a project that builds on that. The reusable library project should ideally be at an abstract / generic level where no mapping is required - mapping is on a per project basis, and you don't want to have to do it twice.)

----------

If your Test Cases will have to change to accommodate the bleeding edge features, then another way would be to version the project:
Version 1.0 contains Deliverable Test Cases from release 1.0
"Create New Version" copies this project under a new version number.
Version 1.1 can contain the changes necessary for the upcoming release, and version 1.0 remains as a maintenance version to be run against release 1.0.

The two projects are then separate, so if your maintenance version requires test changes that are also necessary in the new version, then those have to be done twice.... which isn't ideal if that happens a lot, but acceptable if it doesn't (in my experience the latter is true, but that doesn't mean it is always the case).

Hope that's useful!
Alex

]]>Alexandra Schladebeck2013-02-01T07:13:58-00:00Re: Same AUT Definition for multiple Projects / etc.https://www.eclipse.org/forums/index.php/mv/msg/452361/1006737/#msg_1006737
First of all ... you make me proud Your description of a possible organisation/structure of Test-Projects/-Suites/-Cases is (nearly) exactly what i was laying out in my mind.

Actually i would "widen" the Testcase-Layer a bit and (as you mentioned already) support it with an underlying Layer of useful stuff for every Testcase. Think of fracturing the Testcase-Layer into multiple TestCase-Projects for every person who might be included in the creation of testcases. I'll happily use your draft to lay out my solution:

The reusable library project should ideally be at an abstract / generic level where no mapping is required - mapping is on a per project basis, and you don't want to have to do it twice.

is kind of a miracle to me ... but i need to get my feet wet with that. It sounds very reasonable and i guess it is learning by doing and deleting that what went wrong

You already mentioned the "on a per project basis" ... which is how i created all the above mentioned "Layers" (i put everything in its own Project and hence do need a "new but still the same" AUT Configuration for every new Project)
- is this wrong?
- should i put this all under one Project?
- will it be usable/editable by multiple players at once, when all layers are in the same project?
- is there a way to define an AUT which is usable by more than one Project?

For example it is (rightfully so!) forbidden and taken care of that you cannot perform concurrent edits of project-properties. Will this kind of pessimistic locking experiences not pop up at more places if everything is in one project?

Thank you for your time! (even more as i now did write a lot more )
Daniel

P.S.: Concerning the raw xml editing ... it felt already wrong while doing it ... but it definitely is a simple and quick way of getting an AUT in a new Project. Even more as the "handmapped" mappings are related to the AUT and stored in its xml-structure. I had worries that the ID-Attribute of the AUT-tag might collide with its original but while working creatively with what was given to me i came to the conclusion that if the same AUT - ID exists in two separate Projects then they are still two differently (per project) managed AUTs (so the ID is propably uniqe per project?)

phew, sorry for the textwall ]]>Dan H.2013-02-01T16:18:05-00:00Re: Same AUT Definition for multiple Projects / etc.https://www.eclipse.org/forums/index.php/mv/msg/452361/1007486/#msg_1007486
Glad the information was helpful

One thing to bear in mind is that you may not need two separate reusable projects for separate people. If the idea is that both are working on specific Test Cases for the projects, then they should both work in the same project (multiple users can work on one project in e.g. an Oracle database).

Back to the AUTs / configs:
- AUTs and configs are not shareable
- Therefore having one project that is really responsible for the actual specific tests is entirely preferable. Everything in that project can use the same AUT definition, configurations and mapping. Reused projects contribute very generic modules that are e.g. usable for more than one project at your company.
- That means that if you are currently working with Jubula on one team, then my pragmatic advice would be to work all in one project for now. Test Cases can always be moved out later if other teams want to benefit from your excellent generic modules