Ideas for v4

[Daniel Cazzulino]

Hey guys, 

I wanted to gather your ideas on what would be cool and evolutionary for Moq moving forward to v4 RTM. 

I do have quite a bit of work to do on the Linq provider (i.e. providing a Mocks.First<T> that makes it easier to quickly configure a mock, supporting query syntax over a MockRepository so they are all created the same way, etc.), but I'm sure there are other aras where you'd like to see new stuff coming.

So I'm all "ears" :)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Jason Jarrett]

I threw a question out there a while ago, and don't remember where it ended up (I think you thought it was an interesting feature...).

I'd like to see a way to setup "default" return types for things.

EX:

[TestFixture]

public class MoqSpike

{

public interface IFoo

{

IList<int> BarList();

IEnumerable<int> BarListEnumerable();

}

[Test]

public void Should_be_able_to_setup_default_return_types()

{

var mockDefaults = new MockDefaultsCollection() //Totally made up class name... (TODO pick better name)

.Add<IList<int>>(new List<int>())

.Add<IEnumerable<int>>(new List<int>());

Mock<IFoo> mockFoo = new Mock<IFoo>(mockDefaults);

mockFoo.Object.BarList().ShouldNotBeNull();

mockFoo.Object.BarListEnumerable().ShouldNotBeNull();

}

}

[Emanuele DelBono]

Hi Daniel!
I really LOVE Moq and I love it because is easy, simple, small,
elegant. It has exactly what a mock framework should have in the right
place.
So i f you are planning a new version please don't add too new
features that will bloat the framework :-)
Maybe some features could embrace the new .NET 4.0 Fx like dynamics and so on.

BTW I like it as it is, really :-)


ema
http://blog.codiceplastico.com

[David Taylor-Fuller]

What I would like to see is the ability to to do mock sequencing. I have put together my own little workarround built on the callback mechanisim. However, it would be nice to get proper support.

[Kenneth Xu]

Currently, Moq doesn't support wait/pulse. It changes the
synchronization behavior. Basically, you get dead lock if there is
wait/pulse in the class being mocked. I have reported earlier and
checked that this is not an issue of DP. It would be nice if this can
be fixed.

Thanks,
Kenneth

[andreister]

Can you, by any chance, make ".Object" property on mock redundant?

I know it's not possible with C#3 but perhaps C#4 brings some
interesting options...


--Andrew


On Oct 31, 4:15 am, Daniel Cazzulino <k...@clariusconsulting.net>
wrote:

[Daniel Cazzulino]

not sure how C# 4  would help here... have you seen anything in the new stuff that might apply to that?

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Chris Missal]

I don't know of a way, but definitely worth finding out or investigating, +1.

--
Chris Missal
http://chrismissal.lostechies.com/

[Chris Missal]

Without looking at any Moq source code right now, this seems to get the job done in a tiny test:

    public class Test<T>
    {
        public T Object
        {
            get;
            set;
        }

        public Test()
        {
            Object = Activator.CreateInstance<T>();
        }

        public static implicit operator T(Test<T> testObj)
        {
            if(testObj == null)
                return default(T);
            return testObj.Object;
        }
    }


Can this be applied to get the .Object working redundantly? Or am I way off here?

[Daniel Cazzulino]

That only compiles if the T is a class. 

Implicit cast to interface doesn't compile. 

I reported this via Connect (it's in the moq source code too) and doesn't look like it will get fixed anytime soon.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Chris Missal]

I figured there was more too it, thanks. :)

[Andrew Kazyrevich]

Dunno.. was thinking about "dynamic" here, but it's not type safe and it's kinda plain reflection... 

Really not sure, was just spitballing. 

(There is a "bad way" as Rhino does by declaring extensions on "any T" but not sure I'd like to see this approach in Moq)

--Andrew

[Daniel Cazzulino]

On Mon, Nov 9, 2009 at 17:42, Andrew Kazyrevich <andre...@gmail.com> wrote:

Dunno.. was thinking about "dynamic" here, but it's not type safe and it's kinda plain reflection... 

and without any intellisense whatesoever :(

[alex2k8]

Hello,

I would like "Capture parameter passed to mock object call" to be
implemented in next version.
http://groups.google.com/group/moqdisc/browse_thread/thread/6450f64a568d02e1?hl=en

The patch for current version was sent.

Regards,
- Alex

[andreister]

What about going the extra mile and supporting mocks for static and
nonvirtual methods? ;)

--Andrew

On Oct 31, 4:15 am, Daniel Cazzulino <k...@clariusconsulting.net>
wrote:

[Daniel Cazzulino]

over my dead body! :P

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Krzysztof Koźmic (2)]

+1

it's not MoQ issue that you can't test your code - it's your code'
issue.
If your code is testable, MoQ is more than capable of helping you test
it.

On 10 Lis, 19:43, Daniel Cazzulino <k...@clariusconsulting.net> wrote:
> over my dead body! :P
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

[andreister]

I will respectfully disagree :)

[Kenneth Xu]

I agree with Krzysztof and Daniel. People end up with a better design
after they made their code unit testable by avoiding static methods
and non-virtual. Adapter pattern works with legacy libraries to avoid
strong coupling and gain testability.

2009/11/12 andreister <andre...@gmail.com>:

[gerry_lowry (alliston ontario canada (705) 250-0112)]

<https://svn.castleproject.org/svn/castle/trunk/Tools/Castle.DynamicProxy2/>
is broken.

"Moq uses Castle DynamicProxy internally as the interception mechanism to enable mocking. It's merged into Moq binaries, so you
don't need to do anything other than referencing Moq.dll, though." ~~ http://code.google.com/p/moq/


any idea where the broken link is currently stationed?


Thank you.
Gerry

[Daniel Cazzulino]

I'm not understanding where the problem is that you're having.

Moq has its own version of castle DP, and it's embedded in Moq.dll. You don't need anything else.

If you need a version of Moq without the embedded DP for whatever reason, you'll have to build from trunk.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

--
Post: moq...@googlegroups.com
Unsubscribe: moqdisc-u...@googlegroups.com

[Jonathon Rossi]

The DynamicProxy source code moved into its own trunk, however it is extern'ed into the full castle trunk.

You can now just checkout and build just DP from:
https://svn.castleproject.org/svn/castle/DynamicProxy/trunk/

It is probably better to point to http://www.castleproject.org/dynamicproxy/index.html as the DP home page rather than subversion.

--
Jono

[Daniel Cazzulino]

I still don't understand what do we have to do with how the DP trunk is structured or moved around :)

We just grab their latest public binaries. We don't link to their sources in any way.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Jonathon Rossi]

The Moq homepage does under the "Who?" section.

[Daniel Cazzulino]

gotcha!

fixed!

thanks :)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Jason Jarrett]

Is there going to be some sugar with Moq and C# Named/Optional parameters?

This idea just came out of nowhere, but I'm curious to hear what everyone thinks...

First off, is named/optional parameters supported with interfaces in C# 4.0? Or is that thought of as an implementation detail and interface contracts shouldn't specify "defaults".

Assuming they can. (I don't have time to install Dev10 and spike it)

Given this interface

public interface IService

{

   void Calculate(byte p1, decimal p2 = 2.3m, decimal p3 = .05m, int p4 = 123);

}

Where currently (in C# 3.5 land) we do this this...

MockService.Setup(s => s.Calculate( It.IsAny<byte>(),

It.IsAny<decimal>(), // optional

It.IsAny<decimal>(), // optional

It.IsAny<int>());  // optional

could look like this in C# 4.0...

MockService.Setup(s => s.Calculate( It.IsAny<byte>(),

/*I have no idea how this syntax would look, but let's pretend you get my point */

p3: It.IsAny<decimal>() ); // as opposed to the "default = .05m" specified in the interface

So the mock recording would pickup any calls to this Calculate where the p1 is any byte, the p3 is any decimal and p2 & p4 are their "default" values.

Thoughts? (am I making any sense?)

--~--~---------~--~----~------------~-------~--~----~
Post: moq...@googlegroups.com
Unsubscribe: moqdisc-u...@googlegroups.com
-~----------~----~----~----~------~----~------~--~---

[Daniel Cazzulino]

great feature Jason! definitely sounds useful.

interfaces can indeed have default values specified for parameters.

could you create a new Issue for this? would love to track it and hopefully implement it for v4 :) (I'll change it to Improvement category later, don't worry)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Jason Jarrett]

I created an "issue" - I'm assuming you are the one who turns it into an "enhancement" because currently it's a "defect" and I couldn't find a way to change that...

http://code.google.com/p/moq/issues/detail?id=221