Ask a Question

Testing with a dynamic built menu structure

Occasional Contributor

Testing with a dynamic built menu structure

Our product is an application, using Electron, that builds its menu at runtime based on what items are installed / mounted.


I have three manuals installed, and the structure looks like, with subordinate choice expanded:

  1. A1
    1. A2
      1. A3
  2. B1
    1. B2
      1. B3
        1. (B4 Optional additional filtering, will always be present in this item, but not in every item)
  3. C1
    1. C2
      1. C3


We have nine items that we need to test against. When creating the tests, is it a better choice to install all 9 manuals so that the menu is consistent, or will I be able to mount and unmount (possibly through API calls) and use name mapping options to ensure I find the correct elements? They all map as Panel objects, but all contain unique text, so contextText could be a way to differentiate. Mapping seems to be fairly stable... when A, B, and C are installed they so far have all mapped the same way.


Thus far, in building some preliminary tests... If I design the tests with A installed, then install B, (with both installed) it selects the objects for B instead of A. It should click on A1, A2, then A3, but will reliably click B1,B2, B3. NameMapping has been changed so that contentText is part of the criteria. If I uninstall A, and have only B installed... TestComplete cannot find any of the menu objects. This is why I am thnking it may be best to ensure all our test manuals are installed when building and running tests.

Esteemed Contributor

I think, for easy of testing and constructing the mapping structure, it would be best to have them all installed for your automations.  That just makes sure that the application isn't dynamically changing all over the place.


However, it is not impossible to mount and unmount during the tests.  Just that it will take a lot more code and development time to handle.  You'll end up NOT mapping those menu structures/manuals and using Find, FindChild and similar methods for locacting and identifying your objects.

Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
Occasional Contributor

I had forgotten about Find and FindChild... but yes, the solution that is easier for me to create (and likely for others to maintain) sounds like a good one.


We only test one at a time, but there are no pre-conditions to have only one manual installed at any given time.


Thank you very much for your help.

Showing results for 
Search instead for 
Did you mean: