Ask a Question

Name Mapping for Web Elements shared between different pages

awaldo
New Contributor

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.

4 REPLIES 4
Marsha_R
Community Hero

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.


Marsha_R
[Community Hero]
____
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
https://community.smartbear.com/t5/custom/page/page-id/hall-of-fame

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.

I think you will find that breaking your tests up into modules somehow, whatever works for you, is better in the long run than trying to make one huge test that works for everything all the time. Projects and Project Suites are helpful for that.

 

https://support.smartbear.com/testcomplete/docs/working-with/managing-projects/creating.html

 

 

 

 

 


Marsha_R
[Community Hero]
____
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
https://community.smartbear.com/t5/custom/page/page-id/hall-of-fame

I do understand the idea behind Projects in a suite. We are already leveraging this by creating separate projects for our different country sites, allowing us to share workflows where they are similar, but specify specific differences for each site.

 

I do not understand how splitting off these header and footer tests into a separate project would be beneficial though. It has the same problems as my solution #1 above as it creates additional copies of the elements anyway, but then also adds additional work in maintenance by worrying about an additional project, and then additional problems outside of the test suite with our pipeline. I don't see what we actually gain from this solution that we do not using my proposed workaround #1, and I do see more tradeoffs in implementing it.

cancel
Showing results for 
Search instead for 
Did you mean: