Testing with a dynamic built menu structure

[alan-mullin]

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.

[tristaanogre · Accepted solution]

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.

[alan-mullin]

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.