You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked at some code that could be useful for using this tool on, and discovered a problem. Typically in EJB session/entity beans code in the logic methods you call some variation of:
Without any special care, if you place the dependency annotation in the class containing getAnEntityBeanUtil(), you will record a return value with a halfway living object that wants to do jndi lookup, which will fail in the test run. So you want to mock 2 layers before getting and playing back real return values. We then maybe need a third annotation to indicate this, something like "mockthrough, bypass, mock, chained".
How is this working in the .NET version? Is it supported, and if not, is it not a relevant case for usual programming patterns there?
The text was updated successfully, but these errors were encountered:
Yeah, that will be a problem for us too some time. Perhaps we could scope the dependency to do something like @dependency(scope=DependencyScope.[FOLLOW,THROUGH,BYPASS,CHAIN,etc]) or something?
For legacy code projects in .NET I don't think this a common pattern. There are cases when people use nHibernate and IoC containers it may be tricky to know when to record the dependency. In the example above the actual dependency you want to record is the call to "findSomethingInDB", so in that case I would simply put the dependency on the type returned by getLocalHome(), and not on getAnEntityBeanUtil.
Sure, but getLocalHome() also need special treatment, as running the real code inside it will only work when an application server is running (i.e. lookup in JNDI server), so it need to be replaced by e.g. a mock during playback.
I looked at some code that could be useful for using this tool on, and discovered a problem. Typically in EJB session/entity beans code in the logic methods you call some variation of:
getAnEntityBeanUtil.getLocalhome().findSomethingInDB(aParameter);
I think it is the same as this feature in JMock tries to solve. See question "Can I stub chained getters?" in: http://code.google.com/p/mockito/wiki/FAQ
and
http://mockito.googlecode.com/svn/tags/latest/javadoc/org/mockito/Mockito.html#RETURNS_DEEP_STUBS
Without any special care, if you place the dependency annotation in the class containing getAnEntityBeanUtil(), you will record a return value with a halfway living object that wants to do jndi lookup, which will fail in the test run. So you want to mock 2 layers before getting and playing back real return values. We then maybe need a third annotation to indicate this, something like "mockthrough, bypass, mock, chained".
How is this working in the .NET version? Is it supported, and if not, is it not a relevant case for usual programming patterns there?
The text was updated successfully, but these errors were encountered: