Session query question

Question

question

SriS Suspended asked Jan 12, '09 SriS Suspended posted Jan 12, '09

Session query question

I'm trying to obtain the IP address of a session within a test case. The documentation suggests that this should work:

[profile sessionID parameter_name_or_query ?default_value?]

See Accessing parameters that are defined in session profiles: The profile field replacement

Right-click shortcut:

Insert > Parameter

I do see this value in the Data view if I pause my testcase after opening the session, but the query just doesn't work for me:

Unable to evaluate "puts [profile s1 ipAddress()]" : Invalid query ipAddress()

Am I doing something wrong?

1 open s1 project:///session_profiles/cisco_router.ffsp   
2 eval    puts [profile s1 ipAddress()]

Sri

iTest

sessionProfileQueryIssue.zip (3.2 KiB)

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2009-01-12T21:10:57Z

KumarS answered Jan 12, '09 KumarS posted Jan 12, '09

If you have defined a parameter named "ipAddress" in your session profile, then the syntax is:

[profile s1 ipAddress]

Query is an XPATH query where you want to get parameters by using XPATH queries.

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 2 · 2009-01-12T22:44:24Z

PaulD answered Jan 12, '09 PaulD posted Jan 12, '09

First, you should understand that IP Address is not a parameter, unless you explicitly added your own parameter named ipAddress or something.

If you're talking about the IP Address property associated with a session, then it is around, but you need to dig a little harder to get it. Use

[profile s1 document/sessionProperties/ipAddress]

You are on the right track to look in the Data view when paused at a breakpoint. You'll see a "profile" node for each active session (with an id attribute referring to the session id). Under that profile node are the parameters loaded for that session. But there is also a document node that has all of the information that was loaded in for that session as well. You can then look through it to find the information you need from that document. In this case, I'm pulling out the session properties and from those, selecting ipAddress.

3

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

KumarS commented · Jan 12, 2009 at 10:47 PM

One word of caution though: testcases which use the structure of the session profile are not guaranteed to be backwards compatible in a new release of iTest. Only parameters are guaranteed to be backwards compatible. So in the next release if ipAddress is stored at: document/sessionProperties/firstGroup/ipAddress, your testcase will break. That is why I recommend that users should parameters.

0 ·

dclaar KumarS commented · Jan 22, 2009 at 11:49 PM

I'm sorry, but this really bothers me!

If I follow your advice, I should leave IP address, port, user id, and password out of my testbed definition, and turn them into parameters?!?! That's just wrong. Not only are parameters harder to see when you're looking at a .fftb file, they are required to actually connect. Or maybe we should define them twice, once as a profile item, once as a parameter? This is just nuts!

0 ·

PaulD dclaar commented · Jan 23, 2009 at 12:08 AM

Admittedly, this does sound like nuts. Our fundamental design model did not really consider the case that the test case needs to call out the actual IP address (or credentials or whatever) that were used by the application when it was opening a session. We are striving to make test cases fundamentally portable, and we failed to recognize that test cases might need to use that information for other purposes other than establishing the sessions. We should be adding a feature to make it easier to access these properties from a session without having to dig through the meta-data associated with the session.

Having said that, I want to mention that many automation-centric users of iTest seem to be determined to parameterize testbed properties. This is something that I've never really understood. The testbed file is simply an XML file that contains the parameters you need for a specific testbed. Why would you want to parameterize them! But if you've done a lot of scripting in the past, then you probably think about reading the device properties from some other file, and then want to replace them just before the session is started. Or you want to pass them in as parameters to the test case and use them at run time. I understand those models, but iTest was designed with the idea that if you need to dynamically choose the devices you are going to use at runtime, then you should either be picking a different testbed on the fly or, if you really need to construct the parameters based on some external system (like a testbed reservation system that supports dynamic topologies) then you should generate an iTest testbed file on the fly when you need one. And that is only something that you should need to do in the regression (headless) environment.

In reality, we're seeing a LOT of different usage scenarios that render some of these basic assumptions built into iTest less than perfect. So we're continuing to work on ways of supporting the kind of extensibility that our users are telling us that they need. One problem we face, however, is that another class of users are continuing to complain that iTest has too much abstraction and that it is confusing to get started with. So we are torn between more simplification and more abstraction.

(Sorry for the soapbox!)

Anyway, in this specific case, it is absolutely true that we could easily add the ability to get these session properties more easily -- and should.

0 ·

question