It would be great to see more collaboration between independent .NET projects with similar goals.
Creating open standards like this might encourage more of the 'healthy diversity' that you see in the Java space, rather than the current situation where we wait for Microsoft to set the standard by including something in the BCL...
Not that the task would be without its challenges... ;)
Now that I like the idea of!
Mock syntax for all all frameworks is one of my general bugbears ... it isn't only frequently convoluted ... but the dependency you place within your tests upon the mock framework you choose is something you can later come to regret.
Interesting idea. The team I'm working with at the moment are trying to get their heads around mocking and choose a container but they don't know enough about each one to make an informed choice. The result is that they may very well make the wrong choice and have a lot of work to migrate from one to another or even find themselves using more than one (where they need to learn another syntax and/or approach). Having an abstraction that standardizes would certainly help reduce the problem for newcomers.
This is a little off-topic, but your listed services misses something I need. Or think I need.
My root-cause is that almost all of my mock-based tests ends up to be tightly coupled to implementation, which makes refactoring hard. I have yet to find out why this happens.
One typical scenario would be the testing of WebForms. The WebForm will be mocked, as will my services/tasks. The Presenter will be under test.
Here's what I usually do: I let the WebForm/mock provide strings, while the service expects objects. The Presenter will then need to create the objects from the strings, however, I consider this an implementation detail. My tests are not concerned about how it's done, just that it is done. How do I test that?
My answer to that question have been to handwrite my mock (or is it a stub?), then ask my mock for the passed object and assert for expected information.
In this way, I can change my implementation without touching the tests. I can let the Presenter do the job, or delegate it to some factory/mapper. If I later need to refactor those helpers, I can do that too.
Which means I'd like to query my mocks for passed information, but I haven't found out how to do that with the usual frameworks.
I suspect that isn't your way, and that you have solved this problem. How do you do it?
Thomas,
In Rhino Mocks, looks for the Do() method. It allows you to do that.
Roy,
This is an interesting idea, but it has one problem. The mocking frameworks that you mentioned has wildly different model for use.
Rhino Mocks uses the record / replay model and is strongly typed, NMock uses expectation as string.
How are you going to create an API that would encompass them both?
Oren: That's the point - The AEIS API should allow , in my mind, either both abilities or just one of them. underneath it will translate them to the standard calls for the frameworks (like LINQ does)
Thomas,
In Typemock Isolator, you can use the DynamicReturnValue or Conditional Return Values
Roy,
This sounds like a good idea, I wonder if it is feasible :-)
I think an idea like this would go a long way, not only toward increase use of mocking; but towards better decoupling of mocking "frameworks" from unit testing frameworks. Let's be honest, a mocking framework depends upon a unit testing framework. If you can't view your mocking framework abstractly from your unit testing framework you can't be as flexible as you need to be.
I think ideas like this should proliferate throughout all the Agile frameworks: mocking, unit testing, code coverage, IoC, etc. Once we can build our own stack as easy as using one of the pre-built stacks the better life will be.
As I said in my note, I think you may underestimate the degree of attachment that mock users have to their syntax. :-)
Nevertheless, I hope it can work and I'll commit to including AEIS in NUnit distributions if the licensing permits it.
Charlie
To "peter ritchie" - I'm not sure what mocking framework you are using, Peter, but the one that I am using is most certainly not tied to any unit testing framework.
Jeff: I'd be leaning more towards the Union idea, with the engine adapters implementing specialied ISupports interfaces that return true false to various features. so, for example mocking static methods, AEIS will ask the provider before each test run whether it supports the features that are used in this API and throw if it does not (even better, try to automatically find and load the provider that does support them!)
The problem with ISupports and throwing at runtime is that it is then not clear to the test author that what's been written won't work. Until runtime.
Most frameworks include numerous constraints built into the syntax to guide their use. Although they certainly don't prevent anyone from writing things that won't work... =)
James: Ayende's blog post is an april's fool's joke (just look at the code)
The same is true for the java post.
I would think that this proposed solution would end up with a fate similar to SvnBridge that Oren has been talking about. Some of the symantics of the different mocking frameworks just aren't that easily bridge-able. Good concept though.