锘??xml version="1.0" encoding="utf-8" standalone="yes"?>亚洲精品永久免费,最新中文字幕一区二区三区,久久电影视频http://www.aygfsteel.com/koradji/category/47735.htmlzh-cnMon, 31 Jan 2011 22:55:51 GMTMon, 31 Jan 2011 22:55:51 GMT60銆愯漿甯栥慾Mock Argument Interceptor - 涓縐嶇嫭鐗圭殑璁捐鎬濊礬http://www.aygfsteel.com/koradji/articles/343822.htmlkoradjikoradjiMon, 31 Jan 2011 14:24:00 GMThttp://www.aygfsteel.com/koradji/articles/343822.htmlhttp://www.aygfsteel.com/koradji/comments/343822.htmlhttp://www.aygfsteel.com/koradji/articles/343822.html#Feedback0http://www.aygfsteel.com/koradji/comments/commentRss/343822.htmlhttp://www.aygfsteel.com/koradji/services/trackbacks/343822.html
Motivation
An Object you need to test is constructing another complex object internally which you cannot access and this object is passed to a collaborator you can replace with a mock.
Solution
Write an Interceptor (a custom jMock Stub ) to intercept the argument passed to the mocked method. The Interceptor exposes the argument, allowing for standard jUnit assertions.
Alternatives
* Use a custom jMock Constraint when the argument's asserted state is simple.
* Use a Fake Object when a class cannot be dynamically mocked.
public StringBuffer describeTo(StringBuffer buffer) {
return buffer;
}
}
The Traditional jMock approach
The traditional way to handle this with jMock is to create a custom Constraint to verify the argument passed into the mocked method. Unfortunatly, this technique can produce a less explict test and a lot of supporting code. The above example handled with a traditional jMock Constraint would look like the following...
public StringBuffer describeTo(StringBuffer buffer) {
return buffer.append(ticketNumber);
}
}
}
While this example works fairly well, each new test method would likely require its own Constraint. When the verification in the eval method becomes complex, it can become difficult to determine why a test is failing. An Argument Interceptor allows for traditional jUnit assertions, providing clearer failures for complex verfications.