Forum Discussion

mikev's avatar
mikev
Contributor
13 years ago

Namemapping - Individual & Merged

New to TC, migrating over from QTP.  I've run across a problem, that I hope you can help me with.  Let's say that I have two seperate applications, each of them are tested on their own.  Different Project Suite entirely.  Each of them will obvioulsy have their own Namemapping.  Testing them individually is fine.



Now let's say that I need to test both of them in a single test.  For example, let's say one application enters data into a database, the other accesses the database.  I'm not talking about database access here, I'm just using this as an example.  One application puts data in, the other application verifies that it made it there.  Two applications, one test.



The only way that I've been told to do this is that I must merge the two Namemapping files together.  is that the case?  If so, I think that it's really hard to maintain.  Is there a way around merging them? 



Additionally, how would you go about putting your Namemapping files in a "common" place?  I think it's a good idea to do that, as you can link them in to a test.  But if they must be called Namemapping, then it causes a problem for this.  How do you folks do that? 

6 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    At this time, your only option is merging.  All the files need to be named, AFAIK, NameMapping.tcNM so you can't have two NameMapping objects in the same project with different names.  Honestly, that's the way I did it with up to 5 applications running at a time in a multi-client system.
  • Thanks Robert.  I'm wondering if there's a way to programatically merge them together at run-time?  Or can you write some code to just temporarily merge them for the test?
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    As far as I know, there isn't.  NameMapping is an object that is utilized at Run time so there aren't really any methods or functions to do a "file merge" of them at run time.
  • I suppose that another solution would be to NOT use the NameMapping file at all.  Just code up some functions and put it in the libraries so you can use them.  I just think that merging is messy and unnecessary (at least in my case).  I wonder if SB will ever implement multiple NM files in a project?  That would be a really good feature for folks that are moving over from QTP.  That's they way that they are used to doing things - you can load (or associate) the OR (Object Repository) for each test.
  • Robert, I've been thinking a bit more about this.  Let's say I have two NM files.  Both applications have a File menu.  When the merge happens, how do you distinguish between the File menu of application A and the File menu of Application B?  Is it because they will actually have different Aliases?  I suppose that's the answer.
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    Not only different aliases, but the NameMapping tree is dependant on a hierarchal structure starting at the system root (Sys) object.  Each app is a process off the Sys object so you would have



    NameMapping.Sys.App1

    NameMapping.Sys.App2



    .  So, MainMenu of App 1 will show as a child object of that app and MainMenu of App 2 will show as a child object of that app.  Because the parent object is different, the child objects will be kept separate.



    NameMapping.Sys.App1.MainMenu

    NameMapping.Sys.App2.MainMenu