Isaac Abraham
Top achievements
Rank 1
Isaac Abraham
asked on 29 Nov 2013, 03:22 PM
public
interface
IFoo
{
IBar GetBar(
string
x);
}
public
interface
IBar
{
void
DoBar(
int
x);
}
public
class
Tests
{
[Fact]
public
void
First()
{
var foo = Mock.Create<IFoo>();
foo.GetBar(
"a"
).DoBar(1);
Mock.Assert(() => foo.GetBar(
"b"
).DoBar(1));
}
}
The above test passes, although it should fail.
5 Answers, 1 is accepted
0
Hello Isaac,
Thank you for contacting us.
This is, in fact, expected behavior. When a function is not arranged, it falls back to its default behavior as given by the mock behavior. For RecursiveLoose, the default is to return the same mock object, regardless of function arguments. For more finely-grained control over return values you can always use explicit arrangements.
Is there a particular reason for you to prefer that functions on RecursiveLoose mocks return different mock objects for different arguments?
Regards,
Stefan
Telerik
Thank you for contacting us.
This is, in fact, expected behavior. When a function is not arranged, it falls back to its default behavior as given by the mock behavior. For RecursiveLoose, the default is to return the same mock object, regardless of function arguments. For more finely-grained control over return values you can always use explicit arrangements.
Is there a particular reason for you to prefer that functions on RecursiveLoose mocks return different mock objects for different arguments?
Regards,
Stefan
Telerik
0
Isaac Abraham
Top achievements
Rank 1
answered on 03 Dec 2013, 01:45 PM
Hi Stefan
Why do I want this? Because of the exact example I showed :-) That assertion should not return true. I understand why it does return true - because you're asserting the "final" mock object call - whereas I hoped that Mock.Assert(() => { }) would assert every mockable call in the expression.
Why do I want this? Because of the exact example I showed :-) That assertion should not return true. I understand why it does return true - because you're asserting the "final" mock object call - whereas I hoped that Mock.Assert(() => { }) would assert every mockable call in the expression.
0
Hi Isaac,
Ah, now I understand. You'd like Mock.Assert to assert all sub-expressions, not just the final one. If we were to implement it like this, however, if you really wanted to assert just the final bit, then you'd have to store it in a temporary variable outside the assert call - a possible nuisance in the other direction. Moreover, reimplementing Assert like you suggest will undoubtedly break existing tests. Given the circumstances I cannot say that your suggestion is a clear win. This feature starts out with -100 points and will have to climb out of the pit, if we are to consider it :)
Regards,
Stefan
Telerik
Ah, now I understand. You'd like Mock.Assert to assert all sub-expressions, not just the final one. If we were to implement it like this, however, if you really wanted to assert just the final bit, then you'd have to store it in a temporary variable outside the assert call - a possible nuisance in the other direction. Moreover, reimplementing Assert like you suggest will undoubtedly break existing tests. Given the circumstances I cannot say that your suggestion is a clear win. This feature starts out with -100 points and will have to climb out of the pit, if we are to consider it :)
Regards,
Stefan
Telerik
0
Isaac Abraham
Top achievements
Rank 1
answered on 03 Dec 2013, 02:38 PM
Stefan,
Actually you wouldn't need to break out the final mocked object - you could pass in Args.AnyString etc. etc. for the earlier arguments in the chain that you are not bothered about :-)
Breaking changes - yes, that would be an issue. Perhaps an optional argument that could be passed in when creating the mocking container etc. that could specify what behaviour you would like to have in this situation?
With either of those suggestions, I think that this shouldn't be a -100 :-)
Actually you wouldn't need to break out the final mocked object - you could pass in Args.AnyString etc. etc. for the earlier arguments in the chain that you are not bothered about :-)
Breaking changes - yes, that would be an issue. Perhaps an optional argument that could be passed in when creating the mocking container etc. that could specify what behaviour you would like to have in this situation?
With either of those suggestions, I think that this shouldn't be a -100 :-)
0
Hi Isaac,
This seems reasonable.
Please, add it into our Ideas and Feedback portal in order to be voted for future implementation.
Thank you in advance.
Regards,
Kaloyan
Telerik
This seems reasonable.
Please, add it into our Ideas and Feedback portal in order to be voted for future implementation.
Thank you in advance.
Regards,
Kaloyan
Telerik