Forum Discussion

awaldo's avatar
awaldo
Occasional Contributor
2 years ago

Name Mapping for Web Elements shared between different pages

I am attempting to automate a test case we have that involves verifying that the Header and Footer elements of our site are present, and work on all of our pages.

 

The problem I am having is that in the NameMapping, the individual web elements can only be tied directly as a child to a single Page object. From what I've read and experimented with, this leaves us with only 2 options:

1) Duplicate the header and footer mappings for every, single, page.

2) Create a wildcard page (https://ourwebsite.com*) and putting the elements in that page entry

 

The problem with #1 is that none of the individual items are in any way linked or referenced to eachother, so if there are any changes to the shared element(s), then we would have to go and change every single one instead of just in once place, which could be decently common considering we revamp our site look more than once a year. Right now this would be a nuisance, but will actually cost us considerable time in the future as we expand our test coverage and the site gets more modernized and we keep adding shared web elements like a chat helper, notification modals, login/account segment, etc.

 

The problem with #2 is that creating a wildcard for the entire website means that Every object recording we would do in the future would automatically be assigned to that wildcard page in the NameMapping instead of the specific pages they belong to, which then just adds an additional step for us to go in and relocate every recorded object where they need to go to avoid an overcluttered mess.

 

Is there a more intentionally designed way to do this behavior instead of these hacks? I feel like this should be an extremely common use case with modern website design.

Keyword Tests
Name Mapping
Web Testing

9 Replies

Sort By
  • rraghvani's avatar
    rraghvani
    Champion Level 3
    2 years ago

    The easier option is to create a seperate project, as what Marsha_R has mention.

     

    In my Project Suite, I have a Project that just checks the header and footer on every page of the website. I have a list of all the URLs that are used on the website, that I iterate through. Navigating to each page, I verify the header and footer contents. If a page is added or deleted, I just update the list of URLs.

     

    I also have another Project, where the name mapping is defined as, for the main page:

     

    ObjectType = Page

    URL = https://community.smartbear.com/t5/* 

     

    and each of the following pages, have the following properties defined as:

     

    ObjectType = Panel

    baseURI = */AlertSite-UXM/ct-p/AlertSite_UXM 

    baseURI = */CrossBrowserTesting/ct-p/CrossBrowserTesting 

    baseURI = */ReadyAPI-Platform-and-Tools/ct-p/ready_api_forums 

    baseURI = */Zephyr-Enterprise-Questions/bd-p/ZephyrEnterprise 

     

    which belongs to the main page.

  • Marsha_R's avatar
    Marsha_R
    Champion Level 3
    2 years ago

    What I would do is make a separate small project to just test the headers and footers. That way you are not forcing the rest of the tests into those name mappings. It also gives you the flexibility to run that test without running all the others.

    • awaldo's avatar
      awaldo
      Occasional Contributor
      2 years ago

      I hope that kind of solution works well for you, but for me it honestly just sounds worse than the other options. I don't really see how this solution would be an improvement on any of our problems, other than being a bit less cluttered in the NameMapping tree.

       

      Creating a new project would then de-couple the header and footer from our normal testing entirely, even more strongly than the #1 option I already thought of. That means when we have to change out our site design, we now have an additional project to remap entirely, not just a set of NameMapping entities. It would be slightly simpler to look at, but more work on maintenance, and then creates awkward decisions for our automated pipeline, requiring us to run 2 (or more if we take this approach to every shared item we add) different run jobs, which complicates our logic, and adds more projects to maintain and monitor.

  • larebshaikh's avatar
    larebshaikh
    Occasional Contributor
    2 years ago

    Running into similar situation awaldo did you find any solution to this because what Marsha_R  is trying to tell is already implemented in my case and I can't distribute it more.

    • awaldo's avatar
      awaldo
      Occasional Contributor
      2 years ago

      My team has switched to a different test suite framework so we're no longer using Test Complete, but it was not implemented before I stopped, and I haven't had any DMs or any other "secret info" since then. If Marsha_R is telling you that it is already implemented, but has not provided you any examples or documentation, then it probably is not implemented, and they just mean "I've given a work-around here, so stop talking about it"

       

      With that said, considering it's taken 9 months for anyone else (you) to mention the issue, but takes only days or even minutes for someone to respond with their preferred method, and it seems that the people responding don't even consider it an issue: It seems the general needs and pain points for people are different from ours, or people like us just don't use the TestBear Community, so this is likely considered a "non-issue" for the product, and likely won't get changed.

       

      It's just one of the limitations and compromises you get for using a packaged product instead of your team building your own framework. If you love the product otherwise, then I would recommend just accepting this is a trade-off, choosing the work-around that works best for you (I've listed 2 of my own solutions here, and the other responders have a 3rd) and move on. If this is just another in a list of problems getting in the way of your needs, then it might be worth considering using a different test solution that makes compromises that better fit you, or even building your own framework using lower-level tools like TestNG/Selenium if you have the time and expertise.

      • Marsha_R's avatar
        Marsha_R
        Champion Level 3
        2 years ago

        Hi @awaldo

         

        If you reread the post from larebshaikh, you'll see that they are saying they have already implemented what I suggested, not that I said anything was implemented nor that I am hiding anything. Since I don't work for SmartBear, I would not be the first one to hear about changes anyway. I have, however, seen items on the Feature Requests list be implemented.  

         

        The behavior you described in the posts is what normally goes on here. Volunteers like rraghvani and I spend time on the forums to offer our expertise and we are happy to keep discussing issues, with no "stop talking about it" implied. What usually happens, even if we try to follow up, is that the original poster disappears. 

         

        If the workarounds are not sufficient to keep the user's work progressing, then there is always the option of logging an issue with Support.

         

        I think you will find that most testing teams have different requirements and different environments and no one is testing anything exactly the way or for the same purpose as anyone else. They will also choose tools and design tests that fit them the best.  

         

        I wish you luck in testing with your new framework.