I know there are "death" tests in gtest, for example the EXPECT_EXIT(statement,...) test which expects the statement to eventually call exit(n) or abort with a signal or something. This passes if the statement does call exit(), but fails if it simply returns from main.
What I was looking for was the opposite, something like EXPECT_NO_EXIT(statement) where the statement returns without calling exit, but simply returns a value. The reason for this, is that if the statement does call exit, then the gtest harness just exits and the whole suite of tests stops immediately.
It doesn't have to be EXPECT_NO_EXIT, but a method to prevent a call to exit in the code-under-test from killing the gtest harness.
You can wrap your statement into a code that will satisfy the assertion if the statement returns control to the caller:
EXPECT_EXIT(
{ statement; std::out << "function did not exit"; exit(0) },
testing::ExitedWithCode(0),
"function did not exit");
Related
I want to verify that a function is not called. The function is executed in an asynchronous block call inside the tested function and therefore OCMReject() does not work.
The way I have tested if async functions are indeed called would be as follows:
id mock = OCMClassMock([SomeClass class]);
OCMExpect([mock methodThatShouoldExecute]);
OCMVerifyAllWithDelay(mock, 1);
How would a test be done to test if a forbidden function is not called?
Something like:
VerifyNotCalled([mock methodThatShouoldExecute]);
OCMVerifyAllWithDelay(mock, 1);
I would recommend using an OCMStrictClassMock instead of the OCMClassMock (which gives you a nice mock). A strict mock will instantly fail your test if any method is called on it that you did not stub or expect, which makes your tests a lot more rigorous.
If that's not an option for you, you can do what you described with:
OCMReject([mock methodThatShouoldExecute]);
See the "Failing fast for regular (nice) mocks" section in the OCMock docs.
Now as for waiting for your code which may call the forbidden method, that's another matter. You can't use OCMVerifyAllWithDelay since that returns immediately as soon as all expectations are met, it doesn't wait around a full second to see if illegal calls will be made to it. One option is to put a 1 second wait before verifying the mock each time. Ideally, you could also wait explicitly on your asynchronous task with an XCTestExpectation. Something like:
XCTestExpectation *asyncTaskCompleted = [self expectationWithDescription:#"asyncTask"];
// Enqueued, in an onCompletion block, or whatever call
// ... [asyncTaskCompleted fulfill]
[self waitForExpectationsWithTimeout:1 handler:nil]
could I interact with functions in my deployed contract without using truffle-contract?
I just want to run and play with my functions to check how they work.
I used MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."});
but it doesn't work.
Any idea or suggestions
Thanks
It's hard to know what you mean by "it's doesn't work", but I guess is that you are not seeing any output when running MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."}); in the truffle console?
If yes, the reason is because invoking a method to an instance of a contract will give you a Future, and you must handle the result coming back from the call in an asynchronous way. For example, if the function return a value indicating that some computation has happened, you can print the returned value in the console by:
MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."}).then(console.log)
If you're writing unit tests (to be executed via truffle test), then you can handle the return value by doing this:
MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."}).then(function(returnedValue) {
// do something with the returnedValue, e.g.
// assert.equal(returnedValue, 3, "The returned value must be 3");
});
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 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.
My test code has the following assert:
testSubscriber.Called.Should().BeTrue("the handler was not called");
When it fails I get the following error message:
Expected True because the handler was not called, but found False.
English is not my native language, but this does not sound right, what should I write in the reason?
The reason should be the reason why your assertion should pass. In your case, it appears you instead wrote the reason it would fail.
That parameter will be directly substituted into failure message. It will make sure not to repeat the word "because", so you can include that in the string which may make the code read more clearly.
Regarding the English for this particular case, the exact language I would use would depend on the situation.
If you are asserting that calling the handler sets Called to true, you might say case:
testSubscriber.Called.Should().BeTrue("because the handler was called");
which would result in the message
Expected True because the handler was called, but found False.
If you are confident that calling the handler will set Called to true, and you are instead trying to assert that the handler was called:
testSubscriber.Called.Should()
.BeTrue("we expected the handler to have been called");
which would result in the message
Expected True because we expected the handler to have been called, but found False.