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.