TestPlan generally uses lazy type conversion: when a variable needs to be a specific type it as converted at the time it is needed. This means that when you assign items in the context they tend to be a direct copy of whatever they are being assigned from. When working with HTML this quite often means it is a string, an XML node, or an XPath response.

There are many situations in which you may want, or need, to convert items into specific types. For that there are special conversion functions:

• typeNumber
• typeString
• typeBoolean
• typeInteger
• typeDateTime
• typeDuration

Forced conversions ensure that at serialization time, perhaps with serialObject→, the correct type is written.

XPath

The XPath is a very important situation to consider. When you evaluate an XPath such as //p/b it isn't possible to know, at that time, what result you want from the object. You could want a list of objects, or you could want the string conversion, or possibly even the numeric value of the contents. For this reason TestPlan stores an XPath result. When you attempt to evaluate the object the generic result is converted to a concrete type.

The moment you use the XPath result in any expression it will be converted to the appropriate type. If you intend on saving the value, or using it sometime later, the generic response type is stored. In these cases it is better to convert the type immediately.

set %NumParas% as typeNumber (response count(//p))
set %Title% as typeString (response //title)

This is one of the few places where you may get a memory problem using TestPlan. The XPath result objects are memory pigs. If you store many of them in maps in a loop you'll find yourself running low on memory. It is best to convert them and not store the original response object.