Forum Discussion

Sbu's avatar
Sbu
Occasional Contributor
7 years ago

The "Custom Properties" tab choice should be persistent

Hello,

 

At our company we have been starting to use Soap UI NG a lot to test our REST Apis and one thing we do in particular is heavily rely on the "Custom properties" tab located next to the "TestCase Properties" tab, because our tests use a lot of these to communicate context accross our tests. This tab is by default hidden behind the "TestCase Properties" tab.

 

The problem is that everytime we load a step/case/suite/project, the UI resets the default behavior thus putting the "Custom Properties" behind the "TestCase Properties" tab again. 

 

This would be perfectly fine if we used this tab once or twice a day, but to be honest, we never use the "Test Case Properties" at all and it's probable that in our process the "Custom Properties" tab contains the first info we need when opening a step/case/suite/project. These seconds taken everytime add up very fast and can become frustrating in the long run.

 

Would it be possible to at least make the choice of displaying "Custom properties" tab persistent during the program session ?

 

Thanks for your answers.

4 Replies

  • groovyguy's avatar
    groovyguy
    Champion Level 1

    I used to have the same problem and realized that using the Custom property tab became more of a nuisance for more reasons that what you are seeing. I started to use Property test steps to store my necessary properties. It's easier to work with for clean up and copying and you don't have to fight with the UI.

  • nmrao's avatar
    nmrao
    Champion Level 3

    Interesting topic with a different perspective.

    Here is what my little experience with this tab; rearely have to go that tab and look at the properties.

    I would think, that is designed and kept there like that after a thought process only.

    Here are the use cases for the same and I practice:

    1. Usually I do not have to set them manually / edit the values any time.

    2. These properties are set automatically by:

         a. Groovy Script Test step
         b. Script Assertions
         c. Setup / Tear Down scripts

    3. Rarely use them manually if there are any static values either for case / suite / project level and still being flexible and not hard-coded values.

    4. At times, also use property file and load all of them in one go.

    So, basic idea, I assume, is for automation & no hard-coded scripts, flexibility.

    Would love to hear your use cases.

    • Sbu's avatar
      Sbu
      Occasional Contributor

      But... the core of the problem isn't the fact that we use the tab too often (it was created for a reason, right ?). It's that the way we use the UI is not persisted in a flexible way.

       

      In fact this tab is the only place where we can get a quick view access to values stored during tests at different scopes (step, case, suite, project). It's also the only place we can check our environment variables are properly set on the project properties.

       

      We are a team of developers and this tab is more or less equivalent to any debugging interface giving the state of the data. This is why it is of primary importance for our team.

       

      By the way thanks