I'm trying to make a function that sets the environment up so that I don't have to do it every single test I make.
I've made a function that returns the value IPage, which it does. However, when it passes through a function, a value "IsClosed" gets changed from false to true. This causes the test to fail the second it hits page.gotoAsync();
Picture of Function
Before the return
After the return
Edit: I would like to add that the page variable does act normal with its functions after being returned. Even the syntax auto completes and everything.
Related
I have a method:
-(void)startTaskForResult:(long long*)result {
...
}
The function I want to unit test invoke above function:
-(void)doWork {
long long result = 0;
[self startTaskForResult:&result];
}
I am using OCMock library to do unit tests. In my test case, I want to set the result argument to an mocked value e.g. 100 without care about the actual implementation of -(void)startTaskForResult:(long long*)result.
I tried the following way:
-(void)testDoWork{
// try to set 100 to argument 'result'
OCMStub([classToTest startTaskForResult:[OCMArg setToValue:OCMOCK_VALUE((long long){100})]]);
// run the function, but it doesn't use mocked value 100 for argument 'result'
[classToTest doWork];
...
}
But, when I run my test, it does't use the mocked value 100 for argument result. What is the right way to set mocked value to argument in my case then?
Few points to answer your question:
Code for your problem:
- (void)testDoWork
{
id mock = OCMPartialMock(classToTest)
OCMStub([mock startTaskForResult:[OCMArg setToValue:OCMOCK_VALUE((long long){100})]]).andForwardToRealObject;
// set your expectation here
[classToTest doWork];
}
To solve your particular problem:
Your object should be partial mock
Your method should be stubbed (you did it)
Your stub should be forwarded to real object (i assume you need method startTaskForResult: implementation to be called)
However, you face the problems because you are using wrong approach to test;
There're 3 most common strategies to write unit tests:
Arrange-Act-Assert used to test methods
Given-When-Then used to test functions
Setup-Record-Verify used to test side effects. This usually requires mocking.
So:
If you want to test that startTaskForResult: returns particular value - you should call just that and expect return value (not your case, method return type is void)
If method changes the state of object - you should expect that state change, like property value or so
If calling of doWork has a side effect of calling startTaskForResult:, you should stub it and expect it's call, almost like i've written in code above. However (!!!), however you shouldn't expect things like this. This is not a kind of behaviour that has much sense to test, because it's internal class implementation details. One possible case, when both methods are public and it's explicitly stated in class contract, that one method should call another with some preliminary setup. In this case you expect method call with some state / arguments.
To have your application code testable, you require continuously refactoring your code. Some code is untestable, it's probably better to adopt application code rather then try to cover it with tests anyway. You lose the initial goal of tests - refactoring safety and low cost of making changes.
I am using Cmocka for unit test and that cannot be changed.
I am testing part of my software which invokes callback functions, if a value changes, indicating which data item changed and what the new value is.
The callback functions have this signature:
typedef void (* Value_changed_call_back) (int item_Id, int new_value);
For unit test, I want to register some callback functions and ensure that they are actually invoked, and that they receive the correct parameters.
I can use expect_int() in my mocks, to validate that they are invoked with the correct parameters.
But, I don't see how I can use will_return() since my call back functions are of type void (and that can't be changed).
How would I declare a mock callback function and verify that it is called with the correct parameters? Note that if the function is not called, then the test should fail.
I saw this post and thought about this in CMocka API.
You can use expect_function_call(func) to indicates which function should be called and function_called() in the callback to mark the function as called.
I'm not sure since how long this feature is available (but present in 1.1.5 version).
I answered to this question in case someone comes across this topic even if it's a 2016 ask.
I think the best way to do what you want is to create a stub for the callback and register that. Then inside the callback you set some global variable to a value. Then you would be able to assert that value that gets set in your stub function. This works so long as the assert and the callback are executed on the same thread to make sure that the assert is not a race condition.
I'm trying to setup a mock function that will return a value which is based on the input. The only way to access the input parameter that I know of is via the WillExecute method. However, you have to specify a When clause, and that When clause expects me to define an input value along with the method, in the following fashion:
aMock.Setup.WillExecute(function ...).When.myFunc(1);
I'm kinda forced to say: call that anonymous function, whenever myFunc(1) is called. I'd like to be able to do the same, but on every possible parameter to myFunc, with a kind of wildcard marker in the parameter to myFunc (conceptually):
aMock.Setup.WillExecute(function ...).When.myFunc(*);
Is something like this possible? Basically a When clause that will match any value passed as parameter.
Someone might be tempted to point out the WillReturnDefault value, but method does not have access to the actual parameters of the call, as WillExecute does, so I won't be able to setup anything but a constant value.
Thanks.
Ok, I missed the fact that there was an overloaded version of WillExecute that will do exactly that:
//Will exedute the func when called with the specified parameters
function WillExecute(const func : TExecuteFunc) : IWhen<T>;overload;
//will always execute the func no matter what parameters are specified.
procedure WillExecute(const AMethodName : string; const func : TExecuteFunc);overload;
This way I can tell the mock to execute the passed anon whenever the method is called, regardless of its parameters, while still providing access to them. Exactly what I was looking for. Closing question. Thanks.
This can also be solved by using parameter matching:
aMock.Setup.WillExecute(function ...).When.myFunc(It0.IsAny<Integer>);
I have a class method Juxtaposition.generate_for(position) on a class that I am calling from a spec. The method sets up a map reduce and calls it map_reduce(map, reduce).out(merge: "juxtapositions")
The position variable is defined in a let prior to the it block.
When executing if I simply call the function above (which is really only calling a map reduce on data related to the position) then tests like below fail:
Juxtaposition.count.should eq 1
Juxtaposition.first.value.should eq values
However, if I call
Juxtaposition.generate_for(positions).first["value"].should eq values
prior to the two tests then they both pass. The above two tests also pass when I use pry and call the generate_for method from there.
Is there some strange behavior of map reduce in mongoid that I should be aware of? Or, is there some way to force the results into my later queries.
Solution was simple enough. I just need to make sure to call find on the call to map reduce.
More specifically:
map_reduce(map, reduce).out(merge: "juxtapositions").first
or
map_reduce(map, reduce).out(merge: "juxtapositions").to_a
Without to_a or first the actual map reduce doesn't execute it seems, even if it's meant to be stored in another collection.
I'm having some trouble understanding how to use coroutines properly with luabind. There's a templated function:
template<class Ret>
Ret resume_function(object const& obj, ...)
Where (Ret) is supposed to contain the values passed to yield by Lua.
My current points of confusion are:
What happens if the function returns rather than calling yield? Does resume_function return the function's return value?
How are you supposed to use this function if you don't know ahead of time which (or how many) parameters will be passed to yield? For example, if there are multiple possible yielding functions the function may call.
What is the type of Ret if multiple values are passed to yield?
Am I just entirely mistaken as to how all this works? I envision something like this. On the Lua side:
local img = loadImage("foo.png")
loadImage would be a C++ function which requests the image to be loaded in a different thread and then calls lua_yield, and some time later luabind::resume_function gets called with img as a parameter.
Should I pass "foo.png" to yield as a parameter? To a different function before I call yield, and then never pass any values to yield? What's the right way to structure this? I'm obviously misunderstanding something here.
Where (Ret) is supposed to contain the values passed to yield by Lua.
Luabind only supports single return values, so it only will return the first value passed to coroutine.yield.
What happens if the function returns rather than calling yield? Does resume_function return the function's return value?
Yes, you get its return value.
How are you supposed to use this function if you don't know ahead of time which (or how many) parameters will be passed to yield? For example, if there are multiple possible yielding functions the function may call.
That's up to you; they're your functions. You have to develop conventions about what the yielding function(s) receive as parameters, and what the function resuming the coroutine provides.
What is the type of Ret if multiple values are passed to yield?
Whatever you want it to be. It's the template parameter. The number of parameters to a function has no bearing on the return values that the function provides.
Remember: Lua functions take any number of parameters and can return anything. All Luabind can do is pass along the parameters you give it and convert the return value from Lua functions into what you expect that return value to be. Luabind will do type-checking on the return value of course. But it is your responsibility to make sure that the functions yielding/returning will return something that is convertable to the type the user provides for Ret.
loadImage would be a C++ function which requests the image to be loaded in a different thread and then calls lua_yield, and some time later luabind::resume_function gets called with img as a parameter.
If you're using Luabind, never call lua_yield directly. The proper way to yield in Luabind is to add an attribute to a function you register that will yield whenever you return from the function. The syntax is as follows:
module(L)
[
def("do_thing_that_takes_time", &do_thing_that_takes_time, yield)
];
That is, a C++ function that yields must always yield. This is a limitation of Luabind, as with regular Lua, you can choose whether to yield or not as you see fit.
Also, don't forget that Lua coroutines are not the same thing as actual threads. They are not preemptive; they will only execute when you explicitly tell them to with coroutine.resume or an equivalent resume call.
Also, you should never run the same Lua instance from multiple C/C++ threads; Lua is not thread-safe within the same instance (which more or less means the same lua_State object).
What you seem to want to do is have Lua call some function in C++ that itself spawns a thread to do some process, then have the Lua code wait until that thread is complete and then receives its answer.
To do that, you need to give to the Lua script an object that represents the C++ thread. So your loadImage function should not be using coroutine logic; it should return an object that represents the C++ thread. The Lua script can ask the object if it has completed, and if it has, it can query data from it.
The place where coroutines can come into play here is if you don't want the Lua script to wait until this is finished. That is, you're calling the Lua script every so often, but if the C++ thread isn't done, then it should just return. In which case, you can do something like this:
function loadImageAsCoroutine(imageFilename)
local cppThread = cpp.loadImage(imageFilename);
local function threadFunc(cppThread)
if(cppThread:isFinished()) then
local data = cppThread:GetImage();
return data;
else
coroutine.yield();
end
end
local thread = coroutine.create(threadFunc);
local errors, data = assert(coroutine.resume(thread, cppThread));
if(coroutine.status(thread) == "dead") then
return data;
else
return thread;
end
end
This function returns a coroutine or the image data itself. The caller of this function should check the type; if the type is "thread", then the C++ thread hasn't finished yet. Otherwise, it is the image data.
The caller of this function can pump the coroutine however much they want with some equivalent of coroutine.resume (whether it's luabind::resume_function or whatever). Each time, check the return value. It will be nil if the C++ thread hasn't finished, and not nil otherwise.