Forum Discussion

bhcommunity1's avatar
bhcommunity1
Contributor
4 years ago

CucumberStudio-TestComplete Integration, Supporting Test Scenarios that touch multiple Web Apps

Overview:

a) We have multiple web-based applications.  It is common for a single test case to interact with multiple web-based applications.

b) Using CucumberStudio project to create BDD Scenarios.  CucumberStudio project is bound to TestComplete project.

 

Two questions about organization and supporting this type of arrangement:

1) Naming and organizing the action words within CucumberStudio.  It seems to me that when users create action words in cucumber studio, they need to indicate (within the name) which web-application it is using.  a) Common functionality exists across web applications ie) login, logout etc... b) this will aid in the automating of the action words/step definitions in TestComplete.  Does this make sense?  Or is there a better way?

 

2) Because we have 1 CucumberStudio project bound to 1 TestComplete project, and we have test scenarios that interact with multiple web based applications, then it seems to me that the TestComplete project's NameMapping has to contain everything.  All the objects for all the applications your test scenarios will touch.  Is this correct?  If I have a test scenario that needs to interact with multiple web-applications (or any type of application for that sort), I have to put all the objects within a single NameMapping - within the one TestComplete project?

 

Seems like it grow very large, very quickly.  Worried about it becoming unmanageable.  Is there a way to support test scenarios like this with more than one NameMapping entity? 

  • hkim5's avatar
    hkim5
    4 years ago

    the benefit of name mapping is that it stores the object identifies for the elements that you are interacting with, such that if in a future release, should there be a significant enough of a change in your applications, you test cases will fail but you would only have to update the object identification properties in one place (and all of the tests referring to that object will now be "fixed" - as in no longer has those identification errors).

     

    with that said, as tphillips  pointed out, you do not need to rely on name mapping for many web applications you are testing since you can just refer to xpath expressions and css selectors using the FindElement() method.

    The downside is that your tests may be more prone to breaking upon future releases and require a bit more maintenance, but if you think that the size of the name mapping repository is a show stopper, this can be a workaround

    def use_no_nameMapping():
  page = Sys.Browser("*").Page("*") #define your web app at the page lvl
  page.FindElement("whatever selector").Click() #now you are interacting with the UI without relying on Name Mapping
  • tphillips's avatar
    tphillips
    Frequent Contributor
    4 years ago

    Yes that is how it's expected to work, everything goes within the one name mapping. We use multiple projects within the same project suite, one of those projects has all the name mapping and the rest just include it as an existing item.

     

    A lot of web stuff can be accessed without using name mapping, especially if you are just using X-path notation.

    • hkim5's avatar
      hkim5
      Staff
      4 years ago

      the benefit of name mapping is that it stores the object identifies for the elements that you are interacting with, such that if in a future release, should there be a significant enough of a change in your applications, you test cases will fail but you would only have to update the object identification properties in one place (and all of the tests referring to that object will now be "fixed" - as in no longer has those identification errors).

       

      with that said, as tphillips  pointed out, you do not need to rely on name mapping for many web applications you are testing since you can just refer to xpath expressions and css selectors using the FindElement() method.

      The downside is that your tests may be more prone to breaking upon future releases and require a bit more maintenance, but if you think that the size of the name mapping repository is a show stopper, this can be a workaround

      def use_no_nameMapping():
  page = Sys.Browser("*").Page("*") #define your web app at the page lvl
  page.FindElement("whatever selector").Click() #now you are interacting with the UI without relying on Name Mapping
    • bhcommunity1's avatar
      bhcommunity1
      Contributor
      4 years ago

      Follow-up.

      1) Web-based application

      2) Have instance were you don't want to use NameMapping to store object, and would rather find it programmatically.

       

      Both replies refer to FindElement.  Which appears to support XPath syntax or CSS selector syntax.  If you go down this route, doesn't the TestComplete "Project" have to specify this when you create your project?  What if you didn't do that?

       

      1) Is there way to enable it after project creation?

      2) Is there another way besides FindElement to locate web-based objects programmatically?