I am trying to unit test an service operation which uses .ToListAsync() function for returning a list. The fake mock of this function always returns count 0.
Can someone please help me to understand why this is happening.
Related
I've developed a function where i use the return function to spit out a list of vectors. Unfortunately there are still a few bugs in my code. Once my function has failed due to error can i recover that list of vectors?
Functions have their own scope, so if a function fails, the function will exit and no return value will be returned. It's difficult to say what's making your function fail without looking at your code. If the failure is due to something you have control of in your code, I suggest you solve it before relying on potentially function bogus results. But if the failure is out of your control (e.g. calling an unavailable external data source) you can wrap your risky code in a try call to recover in the event of an error. I hope this helps.
I have gone through the documentation understand what exactly is stub.callsArgWith here:
http://sinonjs.org/releases/v1.17.7/stubs/
But I could not not understand what it makes sense when we chain it like below:
stub.callsArgWith(1, null, "ok")
.callsArgWith(1, new Error("Error!"));
So, basically what it mean is param at index 1 is a callback function and it should be called with first param = null and 2nd param as "ok". But what I could not understand is in what situation we do chaining of callsArgWith and in what sequence are they get used.
Please help me in understanding what exactly is the meaning of above two lines how they will be executed, mean when will it take 'Ok' and when will it return an error.
In older versions of Sinon (specifically versions 1.5 - 1.7), this was how you described behaviour for consecutive calls.
Otherwise, the second callsArgWith call replaces the behaviour of the first callsArgWith.
So in the your example (and assuming the version of Sinon is v1.5 - 1.7):
stub.callsArgWith(1, null, "ok")
.callsArgWith(1, new Error("Error!"));
When the stubbed function is called for the first time,
it will call the 2nd parameter of the stubbed function with the parameters null and "ok".
The second time the stubbed function is called, it will call the 2nd parameter of the stubbed function with an Error object.
So in the your example (and assuming the version of Sinon is NOT v1.5 - 1.7):
stub.callsArgWith(1, null, "ok")
.callsArgWith(1, new Error("Error!"));
Every time the stubbed function is called it will call the 2nd parameter of the stubbed function with an Error object.
Documentation Link: http://sinonjs.org/releases/v1.17.7/stubs/#defining-stub-behavior-on-consecutive-calls
I'm writing a program in Scala and trying to remain as functionally pure as is possible. The problem I am facing is not Scala specific; it's more to do with trying to code functionally. The logic for the function that I have to code goes something like:
Take some value of type A
Use this value to generate log information
Log this information by calling a function in an external library and evaluate the return status of the logging action (ie was it a successful log or did the log action fail)
Regardless of whether the log succeeded or failed, I have to return the input value.
The reason for returning the input value as the output value is that this function will be composed with another function which requires a value of type A.
Given the above, the function I am trying to code is really of type A => A i.e. it accepts a value of type A and returns a value of type A but in between it does some logging. The fact that I am returning the same value back that I inputted makes this function boil down to an identity function!
This looks like code smell to me and I am wondering what I should do to make this function cleaner. How can I separate out the concerns here? Also the fact that the log function goes away and logs information means that really I should wrap that call in a IO monad and call some unsafePerformIO function on it. Any ideas welcome.
What you're describing sounds more like debugging than logging. For example, Haskell's Debug.Trace.trace does exactly that and its documentation states: "These can be useful for investigating bugs or performance problems. They should not be used in production code."
If you're doing logging, the logging function should only log and have no further return value. As mentioned by #Bartek above, its type would be A -> IO (), i.e. returning no information () and having side-effects (IO). For example Haskell's hslogger library provides such functions.
I understand what recursive functions are, but consider the following example of a function meant to get the local version of data on an item, check if there is new data about it available online based on locally stored cache time, and if there is, updating the local data with the new version, returning up-to-date data about it either way.
function getItemData(id){
var local=getLocalItemData(id);
if(!local.cacheTime.upToDate()){
var newData=getOnlineItemData(id);
updateLocalItemData(id, newData);
return getItemData(id);
}
else{
return local.returnHumanReadable();
}
}
My argument against considering it a recursive function is the fact that it will only end up calling itself on rare occasions when the cache time indicates the data has expired, and that the function only calls itself for convenience.
Instead of using return getLocalItemData(id).returnHumanReadable(); I can use return getItemData(id); because it will return the same result, as the newly saved data won't need to be refreshed again in the several microseconds it will take the function to call itself. Also, it is much shorter: in the actual code, I would use lower level commands instead of those function calls, resulting in code duplication which would make the entire function harder to read and maintain.
So, do you think that my argument makes any sense, or do you consider this to be nothing more than a matter of code organization?
The short answer is: yes it is recursive
It becomes important if you consider a platform that does not support recursion
Since it can call itself, your code will not work on that platform because it is technically recursion
For a trivial case like this replacing the recursive call with getLocalItemData(id).returnHumanReadable(); will allow it to work on this platform. In fact, you can change your code to:
function getItemData(id){
var local=getLocalItemData(id);
if(!local.cacheTime.upToDate()){
var newData=getOnlineItemData(id);
updateLocalItemData(id, newData);
local=getLocalItemData(id);
}
return local.returnHumanReadable();
}
NOTE: If you cannot 100% guarantee that only one call is needed, change the if to while
When testing DateTime objects in PHPUnit (3.7.22), I am making the assertion like this:
$this->assertEquals(date_create('2014-01-01'), $myobject->getDate());
Works nicely till you get an exception, and the exception in not clear enough (like for primitives where is clearly states for example that 1 does not equal the excepted 2).
PHPUnit_Framework_ExpectationFailedException : Failed asserting that two objects are equal.
I could pass the $message parameter to the assertEquals method, with a string containing the object value, but I feel it could go easier.
Any ideas?
You could do something like
$expected_date = new DateTime('2014-01-01');
$this->assertEquals($expected_date->format('Y-m-d'), $myobject->getDate()->format('Y-m-d');
This would make you error message say something like "failed asserting that '2014-02-03 matches expected 2014-01-01'
I had a poke around the phpUnit source, and don't see any hook to allow better display. What I usually do is what you already mention in your question:
$this->assertEquals(date_create('2014-01-01'), $myobject->getDate(), print_r($myobject,true) );
OR:
$this->assertEquals(date_create('2014-01-01'), $myobject->getDate(), print_r($myobject->getDate(),true) );
depending on which is more useful, case-by-case.
I do this anyway, because often I want to include other helpful data in the message, perhaps some previous calculations, to give it context. I.e. to know why a test is failing I often need to know more than just the two objects that should've been equal.