Rhino.Mocks
There are 7 entries for the tag
Rhino.Mocks
My last two posts regarding Rhino.Mocks, attracted quite a lot of attention. Focusing on solution I proposed for limiting complexity around creation different kinds of mocks, one thing was pointed out by few people as not the best solution. Ayende called it "in your face! API design", that is stating the kind of mock you want to create explicitly, via method parameter. I don't think that doing it via method name is any less explicit, but let's not go there. Instead, let's think for a while - why do we need 4 kinds of mocks anyway? All differences boil down...
Just a small idea before I go to work. As follow up to my yesterdays post about Rhino.Mocks. I figured, that instead of supplying arrays of object for constructor parameters, which is error prone and doesn't give you the safety of compiler checks, we can actually insert the call to constructor using Expressions (notice that this is solution that will work only in .NET >= 3.5). Here's quick and dirty sketch of remade method: public TTypeToMock Mock<TTypeToMock>(Kind mockKind, Expression<Func<TTypeToMock>> ctorCall, params Type[] extraTypes){ if (extraTypes == null) throw new ArgumentNullException("extraTypes"); if (ctorCall == null)...
[UPDATE]: Example code is updated. I realized that Kind.Multi is not needed, since you can infer that from passed parameters (when ctorArgs are present, user obviously wants to create MultiMock). I also changed default Kind to Relaxed, since this is the most common one. Ayende wrote today about his ideas for new version of Rhino.Mocks. I like the new syntax (looks similar to what MoQ offers), but there's one more change I'd like to see. Here's the list of all methods of MockRepository, used to create some kind of mock: public T CreateMock<T>(params object[] argumentsForConstructor);public object CreateMock(Type type, params...
Last week I've read quite a few new blogposts about Moq mocking framework. I had looked at it once, when it was first released, but I didn't find it interesting back then. Now that version 2.0 was released I decided to give it a go once again. Here's very simple model I created: It's a class with one method that uses helper object to obtain a value and possibly raise an event. Here's the whole code: public interface IHelper { int Param { set; } ...
I just spent good few hours trying to fight awkward limitations of .NET framework in regard to generics, events, delegates and expression trees. And I'm actually not much further than when I started. It bothers me: why put artificial limitations in regard to delegates as generic constraints? I wish I could do: public IEventManager<T1,T2> Metod<T1,T2,TEvent>(TEvent @event) where TEvent: Func<T1,T2>
(this will not compile, can not use delegates as constraints...) or even better:
public IEventManager<T1,T2> Metod<T1,T2,TEvent>(TEvent @event) where TEvent: void delegate(T1,T2)
This seems to ruin my every idea. Even worse, when I looked for help at Expression Trees, I learned that you can't have...
I've been playing in my limited spare time with Rhino.Mocks, trying to come up with a way to simplify interactions with events, and creating strongly typed IEventRaiser (or something similar). Here's what I've come up with so far: It's not an easy task, but I have few ideas. If you have any ideas or suggestions post them in the comments. I'll submit it to Ayende, so if he likes it you may actually see this stuff in some future version of Rhino.Mocks. Technorati Tags: Rhino.Mocks
I'm currently writing tests for a piece of code that has lot of events flying here and back. Something like: 1: public class Caller 2: { 3: public event EventHandler<CancelEventArgs> MyEvent; 4: 5: public void Call() 6: { 7: if (MyEvent != null) 8: ...