I have created a test with 1 action which contains n actions. Is there any way to check after the execution of each action of the n actions the result if it is fail or pass and proceed accordingly?
Not directly.
A similar idea would be to ask for the current run result status, see How can I get the run result status according to the current report node?, but that is currently unsolved.
You can, however, call your actions, and consume there return value, like this:
ActionSucceeded=RunAction ("myTest [Action2]", oneIteration)
If not ActionSucceeded then
' The Action2 call signalled "failure" (false)
End If
This implies that Action2 must return such a result, like in here:
ExitActionIteration (false)
Beware, however, of the fact that RunAction statements need to be inserted using QTP´s IDE (Insert/Call To Action...), resulting in a RunAction call without brackets. When editing this to the assignment form above (with brackets), make sure you get it right the first time before you save the test -- because if you save a test containing a broken RunAction call, QTP disassociates the called test, and the test will fail at runtime even if you edit the script back to correct syntax. This is due to metainfo that QTP saves invisibly in the script, and if you save an invalid action call, this metainfo is being discarded. (You can see when this happens because the action call will disappear from the test flow view.)
And: If you don´t store the RunAction result in a variable, but use it directly, like in
If not RunAction ("myTest [Action2]", oneIteration) then
' The Action2 call signalled "failure" (false)
End If
the same mess arises: QTP does not understand that this is a valid action call, and it won´t work even if you edit it into back into the original form.
Except for the "beware" hint, the same holds true for LoadAndRunAction, which calls an action at runtime. LoadAndRunAction can be called as a function, and if the called actions returns a value via ExitActionIteration, it returns that value.
Yet another "beware" hint: ExitActionIteration really requires its arguments to be enclosed in brackets, even though it is a Sub (or at least called as a Sub). I suspect this is because it is not a real Sub or Function, but a special statement "patched into" the MS VBScript engine in some exotic way.
Related
I would like to ignore one call placed between other ones that I want to call under the same case test. If I use ignoreothercalls I have not clear if the rest of the calls, following this, will be called. I need the rest, after ignored call, will be called. Or at least, to find the way of stopping ignoreothercalls effect before the end of the test case.
TEST(group, test1){
...
mock().expectOneCall("HAL_AS393x_CommandStrobes").withParameter("cCommandCode",AS393X_CMD_CALIB_RCO_LC);
/*-------------------------------------------------------*/
mock().expectOneCall("HAL_AS393x_ReadRegisters");//I want ignore only this mocked function call
/*-------------------------------------------------*/
mock().expectOneCall("HAL_AS393x_Deinit");
...
}
I would like to leave this call without being tested, and remove it from de test case without gettig expecting calls errors for it:
mock().xxxCall("HAL_AS393x_ReadRegisters"); //-where xxxCall = unkown keyword used for this-
You have to check expectation in between:
mock().expect...
do_something_that_call_mocks();
mock().checkExpectations();
/* Start all over again */
Complete example using checkExpectations() to reset mock() here
I want to check condition in pre exit method, if that condition is false then I have to come out of the method, without calling original method.
As far as I know you cannot. However, you have some options:
Check the original method and see if there is a variable you can set in the pre-exit so the logic in the method is not processed;
Use an implicit enhancement at the top of the method you want to skip, you put the code here that you were planning to put in the pre-exit;
Use an overwrite-exit where you call the original method using me->method( ) whenever you do want to call it. If I remember correctly you have to create the overwrite with the option to have access to the global vars.
I have a small question in my mind. I researched it on the Internet but no-one is providing the exact answer. My question is:
In data flow coverage criteria, say there is a method which finally returns variable x. When drawing the graph for that method, is that return statement considered to be a use of x?
Yes, a return statement uses the value that it returns. I couldn't find an authoritative reference that says so in plain English either, but here are two arguments:
A return statement passes control from one part of a program to another, just like a method call does. The value being returned is analogous to a function parameter. return therefore is a use just like being a function parameter is a use.
The other kind of use in data flow analysis is when a value leaves the program and has some effect on the outside world, for example by being printed. If we're analyzing a method, rather than an entire program, return causes the value to leave the scope which we're analyzing. So it's a use for the same reason that printing is a use.
What is the difference between these two lines?
Set MyMsg = MyMsg.Move(MyFolder2)
MyMsg.Move(MyFolder2)
The first one works just fine.
The second one usually gives an "Outlook is not responding" error.
The MailItem.Move method returns the MailItem that has been moved. Usually, properties return values and methods don't return anything. But for several methods, the designers decided it would be handy to have a return value, so they made them return a value (or object).
When you assign a method to a variable, any arguments must be in parentheses or you'll get a syntax error. If you call a method without assigning it to a variable (because you don't care what the method returns or it's one of the methods that doesn't return a value), then the arguments must not be in parentheses (kind of).
Parentheses, when used in places that the compiler does not require them, are the equivalent of saying "evaluate this before doing anything else". It's like how you use parentheses in order of operations so you can say "evaluate this addition operation before you do this multiplication even though that's not the normal order".
The (kind of) remark above is because most of the time when you "incorrectly" put parentheses around something, it doesn't matter.
Application.CreateItem 0
and
Application.CreateItem (0)
are the same. The second one evaluates the argument before it passes it to CreateItem, but evaluating a single integer takes no time and has no ill effects. The parentheses aren't necessary because we're not assigning the results to a variable, but they're not really hurting anything either.
In your second example, you're telling the compiler to evaluate the folder, then send it to the Move method. I don't know what evaluating a folder means, but I gather it's not good. It probably does something like create an array of all the objects in that folder, or something equally intensive. When Outlook is not responding, it means you gave it such a big job that it hasn't checked back in with the operating system in a timely fashion.
So: Use parentheses for arguments when it's on the right side of an equal sign. Don't use them when it's not. There are a few exceptions to that rule, but you may never need to know them.
There is no difference between the two (you just ignore the function result) unless you actually use the MyMsg variable afterwards - after the message is moved, you cannot access it anymore.
Use the first version.
I have a problem with the sequence model seen in the diagram below, specifically where the System object is creating a new Number. In this case, there is no need for a return message since the function SaveInput(n), both in System and Number, is the end of the line for that portion of the program, but unless I include one, the modeller reshaped my diagram into the other one I've uploaded here, and I can't see how to arrange the messages so that my program will work the way I intend without including the return message (the one without a name) from Number to System, since the functions SaveInput() both return a void.
How should void-returning functions be handled in sequence diagrams so that they behave correctly? I have opened the message properties and explicitly defined it as returning a void, but that hasn't helped.
When A calls operation b in B, the "return" arrow from B to A indicates the end of the operation b has finished its execution. This doesn´t mean that as part of the return message you have to return a value, it only means that the execution is done and you can continue with the next messages. Visually, most tools also use these return messages to manage the life bar of the object.