Added InvokesExtensions to support better readable Invokes configuration

[philippdolder]

• supports faking of methods with 0 to 4 arguments
• throws an exception when the signature of the faked method and the action that should be invoked are different
• invokes can be used like this A.CallTo(...).Invokes((string s, int i) => { arguments.Add(s); arguments.Add(i); });

[danielmarbach]

Thanks Phil, very good and handy addition!

[patrik-hagne]

I will try to merge your changes in during the day, thanks a lot, it looks great!

[danielmarbach]

Hijack on: Hope you also merge my changes ;)

[patrik-hagne]

Yup, will do!

[philippdolder]

Thanks for pulling my changes. I will add the same Syntax for the ReturnsLazily configuration.
Are there other parts where arguments of calls can be used and such a syntax would be nicely readable?

Is there anything I can do to help you get the build on codebetter back to green again?

[patrik-hagne]

Thanks for making the pull request in the first place! I will try to give the build some love soon but I'm going on vacation tomorrow and will be away for a week.

A suggestion for the syntax you created is that the argument list doesn't have to match exaclty.

For example:

The faked method has the signature function foo(int, string, DateTime), it should be legal to call it with these three permutations:

(int)
(int, string)
(int, string, DateTime)

Do you agree?

[philippdolder]

Your welcome. I started loving to use FakeItEasy for my TDD development so it was my pleasure to add this feature.

I have to say that I disagree with you. Let me try to explain why.
I think it is very important to have your tests easy to understand and I'm convinced that all your code needs to be as clean as possible.

In my opinion when you allow to have "partially matching" calls the code tends to become harder to understand. With the strict matching enforced the test runner tells you when you have probably not done it the way you wanted. This holds especially true with overloads:
For example:
Foo (int)
Foo (int, string)

If you have these overloads and fake the overload with (int, string), but used invoke with (int) only, finding the reason for your test failure can become harder. If you get a "Signature Mismatch Exception" it's more obvious. Probably you faked the wrong overload.

That's why I implemented a strict signature matching.

btw. Moq (the Mocking framework we used before starting the transition to fakeiteasy) implemented the equivalent Feature with exact signature matching, too.
EDIT: probably it would make sense to allow "Invokes(() => ...)" without an argument even if the faked method has some arguments to indicate that we don't need to invocation arguments of the fake call. (Moq supports that too)

Enjoy your holidays.

[patrik-hagne]

I agree with you.

I once did implement an extension method for invokes that ignores any arguments, not sure where that has gone!

[philippdolder]

I will add that till the end of April.

Is it possible that we create a pre-release version asap for nuget with that new functionality and the updated libraries (from Daniel Marbach). My teammates get each stuck a couple of times a day because of the old version of Castle.Core.

Please let me know if you need any help

[patrik-hagne]

I would like to make a release a soon as possible, my problem is that work keeps piling up! ;-) I'm trying to get the build totally automated so that it will be easier to push new features. I'm not sure if you're interested in being an administrator of the project. Maybe I should create a "FakeItEasy-account" on github that hosts the official repo and other people than I can have the credentials to this account.

[philippdolder]

Yes, that would be definitely a good option. Though I suppose you create an organization for FakeItEasy and create an organizational repository. Then you can easily manage users that are allowed to commit to certain repositories etc.
Concerning the automated build: I'm continuous integration expert in my company. I think we can get that done soon.
And yes, I'm definitely interested in being an administrator and helping to push FakeItEasy. Though I only have limited time to spend on the project, too.

[philippdolder]

If you add me as Administrator on the teamcity.codebetter site I can help to work out fixing the Release build.
My username there is philippdolder.

If you don't have time to do the administrative work, I can offer you to start creating the FakeItEasy organization here on github. I find some 20 minutes time slots a couple of times a week to do some minor things.

[patrik-hagne]

I will add you as an administrator as soon as I can, the teamcity site seems to be down from here at the moment. I have chnaged the build script so that it does create a package with all different versions now so I think that it shouldn't be a major issue having it published from the team-city site. However it would be nice if the CI-server could automatically kick off a build and publish a package with a version number that comes from a tag in GIT.

For example if I would like to make a new realease all I would have to do is to create a tag in GIT on the revision I want published similar to "v1.1.0.2"

[philippdolder]

Sounds good, nice idea with the build triggering on release tags. I think I can achieve this with the TeamCity VCS Trigger Rules. But I definitely have to try it out

[patrik-hagne]

I have assigned you as an administrator now!

[philippdolder]

As a first step I added the nupkg as a build artifact so that you only need to take the nupkg to publish it on nuget.
Is there another way than github comments to stay in contact? ;-)