Eclipse Community Forums: Jubula » Same AUT Definition for multiple Projects / etc.

Home » Archived » Jubula » Same AUT Definition for multiple Projects / etc.(Do i really have to create the same AUT for every new Project?)

Show: Today's Messages :: Show Polls :: Message Navigator

Same AUT Definition for multiple Projects / etc. [message #1006424]

Thu, 31 January 2013 10:32

Dan H.

Messages: 6
Registered: December 2012

Junior Member

Hi everyone!

Hopefully my slightly provocative Question in $topic Description will not trigger any negative outcome as it was rather "tongue in cheek"ishly formulated. Embarrassed

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 Grin

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 Wink

)
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! Wink

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 Embarrassed

[Updated on: Thu, 31 January 2013 11:17]

Report message to a moderator

Re: Same AUT Definition for multiple Projects / etc. [message #1006607 is a reply to message #1006424]

Fri, 01 February 2013 07:13

Alexandra Schladebeck

Messages: 1613
Registered: July 2009

Senior Member

Hi,

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:

------------

- PRODUCTIVE TEST (your deliverable)
-- Contains all Use Cases for release

- INCUBATION TEST (your bleeding edge)
-- Contains Use Cases that are in progress

---------
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

Report message to a moderator

Re: Same AUT Definition for multiple Projects / etc. [message #1006737 is a reply to message #1006607]

Fri, 01 February 2013 16:18

Dan H.

Messages: 6
Registered: December 2012

Junior Member

That was indeed helpful, Alex. Thanks for your timely response!

First of all ... you make me proud Wink

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:

------------
- PRODUCTIVE TEST (your deliverable) Project
-- Contains all Use Cases for release

- INCUBATION TEST (your bleeding edge) Project
-- Contains Use Cases that are in progress
---------
- (Reusable) Testcases Person1 Project:
-- All Testcases developed by Person1

- (Reusable) Testcases Person2  Project:
-- All Testcases developed by Person2
---------
- Reusable Library Project
-- a reusable "library" project containing Tests at an abstract / generic level
---------

Actually, what you said "Alex wrote:"

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 Very Happy

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 Embarrassed

)
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 Smile

[Updated on: Fri, 01 February 2013 16:20]

Report message to a moderator

Re: Same AUT Definition for multiple Projects / etc. [message #1007486 is a reply to message #1006737]

Wed, 06 February 2013 07:17

Alexandra Schladebeck

Messages: 1613
Registered: July 2009

Senior Member

Hi,

Glad the information was helpful Smile

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 Wink

Hope that helps,
Alex

Report message to a moderator

Previous Topic:	How to check multiple line text in jubula?
Next Topic:	How to check multiple line text in jubula?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 11:39:54 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter