General iTest Topics

[jus4kikz]

Simple question...

I have a prompt that I'm trying to ensure is correct with in the test cases I have, and in doing so iTest checks vs the structured prompt variable using the following:

query : prompt

assert: [string match Router(config)# $value]

and I have a LOT of these, in each of my test cases steps.... so I have 100s of "validation errors"

and, then, when I figure, ok I'll not do this assertion because this is not supported,  I'll just pass the expectedPrompt and foundPrompt to a procedure, but then I get the error saying

checkPrompt -foundPrompt $prmptFound -expectedPrompt $prmtExpected

is also not supported for exporting to tcl because of substitution...

seems like a common problem.. any suggestions?

thanks 

 -Anthony

[OwenL]

Anthony,

Presumably your validation errors occur when rendering the test case to Tcl. Are they "Unary operator '' is illegal"?

If so, they can safely be ignored, the rendered script is OK.

I created a similar test case with assertion "[string match 3750> $value]", the corresponding Tcl is:

-query {prompt()} -assert {[string match 3750> $value]} {

I have verified that the rendered script behaves the same as iTest. This is a bug introduced in iTest 3.3, it will be fixed in the next release. Let me know if this does not address your problem.

Regards,

Owen

[PaulD]

Any reason your assertion isn't just $value == "Router(config)#"?

It does look like there is a bug in the script rendering, because there should be no problem with using [string match Router(config)# $value] as an assertion.  It seems to complain about it being a unary operator, but I don't see why that would be a problem.  We'll look into that.

Regarding calling a procedure, I just tried this and I don't see any problems or warnings rendering it.  I'm just using the "store" processor to store the prompt in a variable and then calling a procedure just as you've shown.  Can you provide more information about the warning you are getting? 

[jus4kikz]

well, I guess the assertion was created automatically by iTest I didnt... I created it with the wizard....

it makes perfect sense to do that as well.

IF I can ignore the validation and my .tcl script will work regardlessly, I will not have to worry about the procedure issue...

The procedure call has variables as arguements... it has the following listed under : " Rendering Limitations "

"Procedural EXEC steps with field substitutions enabled cannot be rendered correctly. Substitutions should be disabled. "

 thanks for the quick responses

  -Anthony

[PaulD · Accepted solution]

There is a flag on each step that controls whether the command field contains field substitutions or not.  For "call" steps this is supposed to be disabled.  However, if you have an older test case (from an earlier release), you could possibly find that checkbox enabled and checked.  If so, you can uncheck it and it should become disabled.  Substitutions are always performed on a call step (as well as certain other procedural steps), and if you have that box checked, double-substitution will happen -- but that is not desireable. 

Anyway, if you uncheck that box (in the step properties under the command that says, "Command contains field substitutions", you should see it become disabled.  Then your rendering warnings should go away.

[jus4kikz]

ahhhh, yes it was from an older version, I'm noticing that it is greyed out and not allowed, thank you.