Forum Discussion

rajs2020's avatar
rajs2020
Frequent Contributor
5 years ago
Solved

Big projects loading slowly - How to manage ?

I have seen a few ReadyAPI composite projects which are very big and load very slowly (about 15 minutes or so). I have some questions about this.

1 - How do we figure out the exact cause of the problem?
2 - Are there any limits to project size in terms of MB of size, number of tests etc., after which the project becomes too slow?
3 - If size is the cause of the problem, then do we just need to split the project into smaller projects?

Thanks.

  • AlexKaras's avatar
    AlexKaras
    5 years ago

    Hi,

     

    > proper Name Mapping to ensure that it defaults to the Aliases

    Well, there is some architecture that is good to be aware of:

    -- Tested application contains some object that you'd like to interact with in test code. This (let's call it physical) tested object contains some properties with their corresponding values. Also this object is located at some level within the objects' hierarchy that exists in the tested application. This is the lowest layer;

    -- Next NameMapping goes. NameMapping may be considered as a table that specifies the rule(s) that let test code to find the tested physical object. The proper set of rules (unique and stable identifiers, depth of search, conditional search, whether or not try to search down the objects' hierarchy) makes it possible for test code to find the tested object when the internal structure of the tested application changes (to some extent) during development or when the values of the properties that are used for object's identification change (for example, when testing on different environments). However the NameMapping itself is not perfect: it depends on the physical objects' hierarchy and might be changed when this hierarchy changes during development (for example, if tested objects are moved from one parent to another or some parents are added or removed). NameMapping is at the middle layer;

    -- Aliases are at the highest level and their purpose it to make your test code to be as independent from the tested objects' hierarchy changes as possible. Aliases are located on top of NameMapping and are linked to it. You can adjust the structure of the Aliases tree very significantly but every element of Aliases tree remains to be linked to its corresponding NameMapping element. Which, in its turn is 'linked' to the physical tested object. So you may consider NameMapping as a translation table between Aliases (that correspond to the tested objects' hierarchy that is convenient to you as a user) and physical tested objects in the application. Note, that, for example, if because of changes in the objects' hierarchy in the tested application NameMapping must be changed (some NameMapping elements must be moved up or down the hierarchy or some new elements must be inserted in-between or removed), those changes will not alter Aliases tree and thus your test code will remain unchanged. Actually, there is no need to use NameMapping object in test code and Aliases one should be preferred one.

     

    With the above in mind, the best strategy with automation with TestComplete is to investigate your tested application before test recording and create NameMapping and Aliases elements that identify the elements you will interact with during recording. In this case TestComplete will use Aliases elements during recording. Also with manual preliminary Aliases design you will get more clean and clear objects tree that better corresponds to the tested objects' hierarchy from the end-user point of view (more flat structure, absence of not necessary intermediate panels, more descriptive names, etc.)

     

8 Replies

Sort By
  • HimanshuTayal's avatar
    HimanshuTayal
    Community Hero
    5 years ago

    rajs2020 : Yes the size of the project is the only problem, you can do below things in order to reduce the project size:

     

    1. While using pdf/excel/text file as Test Data, you can add the link of that file instead of attaching the file(This helps me personally in reducing the project size)

    2. You can split your 1 big project into different multiple projects of same functionality

    3. You can remove all the custom properties added at the time of running after each run(This helps me personally in reducing the project size)

     

     

    • sonya_m's avatar
      sonya_m
      Icon for Alumni rankAlumni
      5 years ago

      Thanks a lot Himanshu for the great answer!

       

      rajs2020  does this help?

    • rajs2020's avatar
      rajs2020
      Frequent Contributor
      4 years ago

      Another thing I'd like to add is that ReadyAPI takes too long (5-10 minutes) to open up when it has a too big project. If you want to make ReadyAPI at least open up quickly, then you can delete your profile settings and then run ReadyAPI. After that, you can load your project and this will take a lot of time. But, at least ReadyAPI opens up first.


      Deleting profile settings -
      1. Go to C:\Users\YourUsername.
      2. Delete default-soapui-workspace.xml.


      I often see too many ready api projects that are too big and can't be broken down. If you break the project down into smaller projects, then you'll have to replicate common things in each project like getting access tokens, deleting test data etc. which is horrible. I wonder if the Smart Bear team has a solution for this sonya_m.