I have seen that in Mockito, the when method is passed a method (say m) and the exact arguments which the m should be called with. Eg.
when(calcService.add(10.0,20.0)).thenReturn(30.00);
Above 30 is returned only if add is called with 10 and 20. Otherwise when returns something undefined.
Is it possible to return 30 irrespective of what argument values are passed to add?
Well, take a look on ArgumentMatchers. You could use
when(calcService.add(anyDouble(), anyDouble())).thenReturn(30.00);
for non null values, or
when(calcService.add(any(Double.class), any(Double.class))).thenReturn(30.00);
or something similar, depending on the actual type of your method input attributes.
Related
Try to make as described:
To convert a string to lowercase, you can call the String.ToLower()
method
let makeUpperCase s =
s.ToUpper()
Get as result
error FS0072: Lookup on object of indeterminate type based on
information prior to this program point. A type annotation may be
needed prior to this program point to constrain the type of the
object. This may allow the lookup to be resolved.
If you want to invoke members of a value that is passed as an argument to a function, you have to give F# some hint about what the type of the value is. The best way to do this is using a type annotation:
let makeUpperCase (s:string) =
s.ToUpper()
F# compiler needs this, because it cannot figure out what ToUpper method are you trying to invoke as there may be many .NET objects that have a method of this name.
I am creating an Alloy model of the iCalendar data format.
An iCalendar file contains properties. There are a lot of codependencies among the properties. I want to see if anything breaks when a property is removed (i.e., when the property is constrained to zero occurrences).
I want to write an assert and have the Alloy Analyzer search for counterexamples, but I am struggling with how to write the assert. I want the assert to say something like this:
If property X is removed (i.e., property X is constrained to zero
occurrences), there are no instances that are invalid as a result of
removing X.
In pseudocode, I want this:
assert NoProblemFilteringX {
(no prop: X | prop in iCalendar.properties) => all instances are still valid
}
Would you provide some guidance on formulating the desired assert, please?
Suggestion:
Write your codependency checks in a predicate taking as parameter a
set of properties. The predicate holds iff the codependencies are satisfied amongst those properties given in parameter.
Rewrite your fact ensuring those codependencies so as to call this predicate with the set of all iCalendar properties as parameters.
Call this predicate in the assert while this time giving iCalendar.properties - X as parameter
For a case in which stubbed variable in made inside the actual production code,
How can we pass actual arguments with stubbing e.g using Mockito.when in JUnits?
E.g if a method in production code is like:
1) servicaClass.doSomething(Calendar.getInstance)
2) servicaClass.doSomething(someMethodToCreateActualVariable())
while testing how a actual parameter can be passed?
Like
-> when(mockedServiceClass.doSomething(Calendar.geInstance)).thenReturn("")
But while testing production code will take its own calendar value while executing.
There can be a way to make public setter getter method for the used variable to be stuffed. But that dont seem to be a optimum solution.
Any pointers with this regard will be helpful?
If you know the matching value before the fact, you can use stubbing. Mockito matchers like eq (compare with equals) and same (compare with ==) will help there, or you can get the eq behavior by specifying the value directly. Note that you have to use Matchers for all values if you use any at all; you can't use Matchers for only one argument of a two-argument method call.
// Without matchers
when(yourMock.method(objectToBeComparedWithEquals))
.thenReturn(returnValue);
// With matchers
when(yourMock.method(eq(objectToBeComparedWithEquals)))
.thenReturn(returnValue);
when(yourMock.method(same(objectToBeComparedReferentially)))
.thenReturn(returnValue);
If you don't know the matching value until after you run the method, you might want verification instead. Same rules apply about Matchers.
SomeValue someValue = yourSystemUnderTest.action();
verify(yourMock).initializeValue(someValue);
And if you need to inspect the value after the fact, you can use a Captor:
ArgumentCaptor myCaptor = ArgumentCaptor.forClass(SomeValue.class);
yourSystemUnderTest.action();
verify(yourMock).initializeValue(myCaptor.capture());
SomeValue valueMockWasCalledWith = myCaptor.getValue();
// Now you've retrieved the reference out of the mock, so you can assert as usual.
assertEquals(42, valueMockWasCalledWith.getInteger());
To illustrate the following example I created a litte spock test (but it's about groovy itself, not spock):
void "some spock test"() {
given: String value = null
expect: someMethod(value) == 3
}
int someMethod(String s) {
return 3
}
int someMethod(Map s) {
return 5
}
There are two methods who's signatures only differ by the type of the given parameter. I thought that when I give it a null value that is explicitly typed as a string, the string-method will be called.
But that doesn't happen; the test fails, because the map-method is called! Why?
I guess groovy ignores the type and treats all nulls the same. There seems to be some kind of priority of types: When I use Object instead of Map as the parameter type of the wrong-method, its all the same, but when I for instance use Integer, the test succeeds.
But than again: If groovy really ignores the type of nulls, why can the following fix the original test:
expect: someMethod((String) value) == 3
If you read my answer to the question Tim already mentioned you will see that I talk there about runtime types. The static type plays normally no role in this. I also described there how the distance calculation is used and that for null the distance to Object is used to determine the best fitting method. What I did not mention is that you can force method selection by using a cast. Internally Groovy will use a wrapper for the object, that also transports the type. Then the transported type is used instead. But you surely understand, that this means a one additional object creation per method class, which is very inefficient. Thus it is not the standard. In the future Groovy maybe change to include that static type information, but this requires a change to the MOP as well. And that is difficult
Hopefully this is what my problem is(having problem reading the error log that erlang prints). I'm trying to search through a list to find a matching string(PID from a client converted to a string) but it just results in a crash.
...
#7 ClientPID = pid_to_list(From),
#8 list:member(ClientPID, #server.users), % 'users' being a list in the record 'server'
...
The 'users' list in the 'server' record is just defined to users = [], if it helps.
Crash report:
** Reason for termination ==
** "{undef,[{list,member,[\"<0.568.0>\",2],[]}, {server,loop,2,[{file,\"server.erl\"},{line,8}]},
{genserver,loop,2,[{file,\"c:/Erlang/ServCli/genserver.erl\"}{line,13}]}]}"
Module is called lists not list. It's common mistake :)
And your argument are little off. You are using record, and proper usage look like this: VariableThatStoresRecord#record_name.filed_name. In your case it could be something like State#state.users (or just shorten State parameter in loop function to S if you don't like this double state).
What you are doing is actually a semantic suger, which returns on which element in record/tuple given field is stored (since all records are in fact tuples). In you case #state.users returns 2 (first element is record name, and I guess that users is first defined field in your record).
Regarding the error message. First thing is thing you get undef error. So it means that you are meking call to undefined function (which is quite common, since Erlang is dynamic language). Than you get list of tuples, which represents call-trace, from newest to oldest like this
[ { function call definition }
{ function call definition }
{ function call definition } ]
The first one is most interesting, since it is the call to undefined function. You can see that it is call to module list and function member. Other than that you can expect either actual arguments, or just arrity (those variables could be garbage collected already in erlang), and some information about function definition (like file and line number).
And from {list,member,[\"<0.568.0>\",2],[]} you can see that you are trying to call list:member function, with arguments "<0.568.0>" and 2. If you change your call to lists:member(ClientPID, Server#server.users) it should work.
Since most of the error messages are usually nested tuples/lists, which are hard to read if they are presented in one line. So what I do is copy them to my editor, split the one-liner into multiple lines, and than auto indent (emacs does this really great, and some editor can follow this lisp-like indention for Erlang).