Say i have a method which populate some data to a list and it internally calls one more method(which i'm testing independently) and that populate some data to the list. Here what is the best way of testing?
How to test the outer Method? Should I check for the data's from inner Method also, else it is ok to test only the data's populated by outer method?
Given the following class under test:
class MyTestClass {
int getAPlusB() { return getA() + getB() }
int getA() { return 1 }
int getB() { return 2 }
}
I can write the following spock test to check that the arithmetic is correct, but also that getA() and getB() are actually called by getAPlusB():
def "test using all methods"() {
given: MyTestClass thing = Spy(MyTestClass)
when: def answer = thing.getAPlusB()
then: 1 * thing.getA()
1 * thing.getB()
answer == 3
}
So far this is running all the code on all 3 methods - getA and getB are verified as being called but the code in those methods are actually being executed. In your case, you are testing the inner methods seperately, and perhapse you do not want to call them at all during this test. By using the spock spy, you can instantiate a real instance of the class under test, but with the option of stubbing particular methods which you want to specify the value returned by:
def "test which stubs getA and getB"() {
given: MyTestClass thing = Spy(MyTestClass)
when: def answer = thing.getAPlusB()
then: 1 * thing.getA() >> 5
1 * thing.getB() >> 2
answer == 7
}
Related
please consider the below code,
class A {
foo() {
int a = logicToGetA();
int _bar() => someOtherLogic(a);
// ..
int b = _bar();
// ..
}
}
class B {
int _bar(int a) => someOtherLogic(a);
foo() {
int a = logicToGetA();
// ..
int b = _bar(a);
// ..
}
}
main() {
for (int i = 0; i < 1000000; i++) {
A().foo();
}
for (int i = 0; i < 1000000; i++) {
B().foo();
}
}
Explanation: class A has bar() nested inside foo() but class B has bar() outside of foo(). in the second case, bar() can be made as a static method as well.
My Doubt: which way is more efficient, if foo() is called multiple times? If A().foo() is called 1000000 times, will A.foo.bar is redefined that many times?
It depends.
If the _bar function can be defined outside of the foo method, then we can presume that it doesn't reference any local variables of the foo method.
In that case, the compiler can optimize the local function to be just as efficient as the instance method. Maybe it does, maybe it doesn't, so let's check.
See: https://dartpad.dev/4a53a91bf4e0006e4af4c8a598b68ee6 .
This is (attempted) written so that the compiler can't optimize away the invocation of _someOtherLogic.
I also tried making the invocation be to a static method (but then having to pass the object itself as argument to give access to the instance getter for flag).
Running this in dartpad gives me a final set of results of
A: 918460 /ms
B: 798960 /ms
S: 918380 /ms
It seems dart2js is more efficient with the local function than with the instance method.
Running the same code on the VM gives a benchmark result of:
A: 625960.0 /ms
B: 723245.0 /ms
S: 625075.0 /ms
showing that it's performance characteristics are exactly the opposite of dart2js.
It's very likely that dart2js inlines the _bar function when it's statically known. The dart2js compiler tend to be more aggressive about inlining than the VM.
All in all, I wouldn't start to worry about this difference unless the function call shows up heavily in the performance profile of a real-world program.
If your program's performance really depends critically on this one function call, I'd probably inline the function. If not, write whatever is more readable and maintainable, and don't start micro-optimizing until you know it matters.
How do I generate unit test for the following method within VS2010 ?
public bool myResult(Func<int, int, bool> myFunc)
{
int a = 1;
int b = 2;
return myFunc(a, b);
}
When I right-click and select "Generate Unit Tests..." the myResult method is not available to select for a unit test. Methods that do not contain Func as parameters do appear.
While the automatic test generator doesn't work, you can just make the unit test manually.
All that is required is to have a method that's flagged with [TestMethod] in your class, and write the unit test(s) yourself.
I am testing whether my class calls a method on a mocked class, with the proper argument. I have set up a basic expectation:
// mListener is a mocked object
// This expectation accepts any argument
EXPECT_CALL(this->mListener, OnChanged(_))
.Times(1);
This is fine, but I also want to verify the argument. It is an object which only has accessors that use output parameters:
// aValue is an output parameter
HRESULT get_Value(int* aValue);
How can I define a matcher that will inspect the value that get_Value puts into aValue?
You could try something like:
MATCHER_P(CheckValue,
expected_value,
std::string("get_Value ")
+ (negation ? "yields " : "doesn't yield ")
+ PrintToString(expected_value)
+ " as expected.") {
int result;
arg.get_Value(&result);
return expected_value == result;
}
which could check that e.g. aValue == 7 by doing:
EXPECT_CALL(this->mListener, OnChanged(CheckValue(7)))
.Times(1);
Sample code below. I'm a little curious why MyActor is faster than MyActor2. MyActor recursively calls process/react and keeps state in the function parameters whereas MyActor2 keeps state in vars. MyActor even has the extra overhead of tupling the state but still runs faster. I'm wondering if there is a good explanation for this or if maybe I'm doing something "wrong".
I realize the performance difference is not significant but the fact that it is there and consistent makes me curious what's going on here.
Ignoring the first two runs as warmup, I get:
MyActor:
559
511
544
529
vs.
MyActor2:
647
613
654
610
import scala.actors._
object Const {
val NUM = 100000
val NM1 = NUM - 1
}
trait Send[MessageType] {
def send(msg: MessageType)
}
// Test 1 using recursive calls to maintain state
abstract class StatefulTypedActor[MessageType, StateType](val initialState: StateType) extends Actor with Send[MessageType] {
def process(state: StateType, message: MessageType): StateType
def act = proc(initialState)
def send(message: MessageType) = {
this ! message
}
private def proc(state: StateType) {
react {
case msg: MessageType => proc(process(state, msg))
}
}
}
object MyActor extends StatefulTypedActor[Int, (Int, Long)]((0, 0)) {
override def process(state: (Int, Long), input: Int) = input match {
case 0 =>
(1, System.currentTimeMillis())
case input: Int =>
state match {
case (Const.NM1, start) =>
println((System.currentTimeMillis() - start))
(Const.NUM, start)
case (s, start) =>
(s + 1, start)
}
}
}
// Test 2 using vars to maintain state
object MyActor2 extends Actor with Send[Int] {
private var state = 0
private var strt = 0: Long
def send(message: Int) = {
this ! message
}
def act =
loop {
react {
case 0 =>
state = 1
strt = System.currentTimeMillis()
case input: Int =>
state match {
case Const.NM1 =>
println((System.currentTimeMillis() - strt))
state += 1
case s =>
state += 1
}
}
}
}
// main: Run testing
object TestActors {
def main(args: Array[String]): Unit = {
val a = MyActor
// val a = MyActor2
a.start()
testIt(a)
}
def testIt(a: Send[Int]) {
for (_ <- 0 to 5) {
for (i <- 0 to Const.NUM) {
a send i
}
}
}
}
EDIT: Based on Vasil's response, I removed the loop and tried it again. And then MyActor2 based on vars leapfrogged and now might be around 10% or so faster. So... lesson is: if you are confident that you won't end up with a stack overflowing backlog of messages, and you care to squeeze every little performance out... don't use loop and just call the act() method recursively.
Change for MyActor2:
override def act() =
react {
case 0 =>
state = 1
strt = System.currentTimeMillis()
act()
case input: Int =>
state match {
case Const.NM1 =>
println((System.currentTimeMillis() - strt))
state += 1
case s =>
state += 1
}
act()
}
Such results are caused with the specifics of your benchmark (a lot of small messages that fill the actor's mailbox quicker than it can handle them).
Generally, the workflow of react is following:
Actor scans the mailbox;
If it finds a message, it schedules the execution;
When the scheduling completes, or, when there're no messages in the mailbox, actor suspends (Actor.suspendException is thrown);
In the first case, when the handler finishes to process the message, execution proceeds straight to react method, and, as long as there're lots of messages in the mailbox, actor immediately schedules the next message to execute, and only after that suspends.
In the second case, loop schedules the execution of react in order to prevent a stack overflow (which might be your case with Actor #1, because tail recursion in process is not optimized), and thus, execution doesn't proceed to react immediately, as in the first case. That's where the millis are lost.
UPDATE (taken from here):
Using loop instead of recursive react
effectively doubles the number of
tasks that the thread pool has to
execute in order to accomplish the
same amount of work, which in turn
makes it so any overhead in the
scheduler is far more pronounced when
using loop.
Just a wild stab in the dark. It might be due to the exception thrown by react in order to evacuate the loop. Exception creation is quite heavy. However I don't know how often it do that, but that should be possible to check with a catch and a counter.
The overhead on your test depends heavily on the number of threads that are present (try using only one thread with scala -Dactors.corePoolSize=1!). I'm finding it difficult to figure out exactly where the difference arises; the only real difference is that in one case you use loop and in the other you do not. Loop does do fair bit of work, since it repeatedly creates function objects using "andThen" rather than iterating. I'm not sure whether this is enough to explain the difference, especially in light of the heavy usage by scala.actors.Scheduler$.impl and ExceptionBlob.
We've been profiling our code recently and we've come across a few annoying hotspots. They're in the form
assert(a == b, a + " is not equal to " + b)
Because some of these asserts can be in code called a huge amount of times the string concat starts to add up. assert is defined as:
def assert(assumption : Boolean, message : Any) = ....
why isn't it defined as:
def assert(assumption : Boolean, message : => Any) = ....
That way it would evaluate lazily. Given that it's not defined that way is there an inline way of calling assert with a message param that is evaluated lazily?
Thanks
Lazy evaluation has also some overhead for the function object created. If your message object is already fully constructed (a static message) this overhead is unnecessary.
The appropriate method for your use case would be sprintf-style:
assert(a == b, "%s is not equal to %s", a, b)
As long as there is a speciaized function
assert(Boolean, String, Any, Any)
this implementation has no overhead or the cost of the var args array
assert(Boolean, String, Any*)
for the general case.
Implementing toString would be evaluated lazily, but is not readable:
assert(a == b, new { override def toString = a + " is not equal to " + b })
It is by-name, I changed it over a year ago.
http://www.scala-lang.org/node/825
Current Predef:
#elidable(ASSERTION)
def assert(assertion: Boolean, message: => Any) {
if (!assertion)
throw new java.lang.AssertionError("assertion failed: "+ message)
}
Thomas' answer is great, but just in case you like the idea of the last answer but dislike the unreadability, you can get around it:
object LazyS {
def apply(f: => String): AnyRef = new {
override def toString = f
}
}
Example:
object KnightSpeak {
override def toString = { println("Turned into a string") ; "Ni" }
}
scala> assert(true != false , LazyS("I say " + KnightSpeak))
scala> println( LazyS("I say " + KnightSpeak) )
Turned into a string
I say Ni
Try: assert( a==b, "%s is not equals to %s".format(a,b))
The format should only be called when the assert needs the string. Format is added to RichString via implicit.