$sessionData object issues

[TripleG]

Opentest version 1.3.8

Issue 1

Cannot add new properties to existing object in $sessionData

$sessionData.cache = {}; //create cache object

//add new property object to the cache object
$sessionData.cache.obj = {
    data: {
        value: "value"
    }
}

$log.debug("$sessionData.cache (returns empty object): " + $json($sessionData.cache));
$log.debug("$sessionData.cache.obj (returns empty object): " + $json($sessionData.cache.obj));

//create the cache property and assign to it fully created object
$sessionData.cache = {
    obj: {
        data: {
            value: "value"
        }
    }
}

$log.debug("$sessionData.cache (works): " + $json($sessionData.cache));
$log.debug("$sessionData.cache.obj (works): " + $json($sessionData.cache.obj));

Output:

15:14:33    WEB 
DEBUG: $sessionData.cache (returns empty object): {}
15:14:33    WEB 
DEBUG: $sessionData.cache.ob (returns empty object)j: {}
15:14:33    WEB 
DEBUG: Publishing session data: {"cache":{"obj":{"data":{"value":"value"}}}}
15:14:33    WEB 
DEBUG: $sessionData.cache (works): {"obj":{"data":{"value":"value"}}}
15:14:33    WEB 
DEBUG: $sessionData.cache.obj (works): {"data":{"value":"value"}}

Issue 2

Cannot access properties containing dot in their names in $sessionData

$sessionData.cache = {
        "obj.1": {
            data:
                { value: "value" }
        }
    };

$log.debug("$sessionData.cache: " + $json($sessionData.cache));
$log.debug("$sessionData.cache[obj.1]: " + $json($sessionData.cache["obj.1"]));

Output:

15:20:28    WEB 
DEBUG: Publishing session data: {"cache":{"obj.1":{"data":{"value":"value"}}}}
15:20:28    WEB 
DEBUG: $sessionData.cache: {}
15:20:28    WEB 
DEBUG: $sessionData.cache[obj.1]: {}

[adrianth]

Working with nested properties in session data and shared data is not supported and will lead to undefined behavior. This is probably something that should be stated explicitly in the documentation. Basically, there are only two things that are allowed: setting a top-level property and reading a top-level property. This is a limitation that should be very easy to work around by preparing the object before writing it to the data store, like you showed in one of your examples above.

The reason for this limitation is that the shared and session data are stores are kept server-side. Every time you read or write a property from those two data stores, an API call is made to the server to set or retrieve the value for that property (which, of course, incurs a performance penalty). This is also the reason why local data should always be used instead, if the test scenario permits.

Please let me know if this limitation affects your specific scenario and if you need assistance in finding a workaround.

[TripleG]

It's always a pleasure for me to waste couple of days trying to figure out how a simple feature as shared data works(or doesn't work, actually). Then figure out a workaround for something that should be a no-brainer.

Thanks!

Btw, are you really concerned about the performance penalty of doing few requests to the server to get the data? What about the parallel execution impossibility? How do the few requests compare to that performance penalty? How many requests do you think one can make to the $sessionData that would actually cause significant delay in execution?

Sorry for my tone, but I am really getting tired of fighting with the framework and trying to find crazy workarounds for features that should be no-brainers. Literally every feature I try to use is a stumbling stone, because either it is crippled because "non-programmers cannot use it, it should be simple", or it is just working in unexpected ways with some non-logical limitations and it causes more confusion and inconvenience than to be actually useful.

[adrianth]

First of all, sarcasm is not welcome on this forum and I'd ask you to please refrain from it in the future. I was not going to respond, but I decided to do so because you previously provided some interesting ideas and some constructive feedback on this project. Also, it sounds like you realized you were out of line in the second half of your message (still not sure why you didn't try to reformulate the first half). That said, you must realize that no test automation product is going to be a perfect fit for your use case and even commercial test automation solutions that charge $3000 per seat are going to have limitations and particularities that will frustrate you at times. Please realize that you are using an open source project that took thousands of man-hours to put together but is provided to you for free. The answers that you receive in this forum might not always give you the perfect solution, but are written with the best of intentions by people who took a little time out of their day to try and help you.

I hope this all makes sense. I will go ahead and close this ticket now.