How to serialize mocked interface

1,005 views
Skip to first unread message

Paweł Tarnik

unread,
Jan 4, 2011, 5:41:26 AM1/4/11
to Moq Discussions
Hi,

I'm trying to mock some simple interface and pass it to the class
under test. Nothing special.
However, CUT needs to serialize instance of that interface (i.e.
mocked object) via XmlSerializer. And here I get an exception:

Castle.Proxies.ISomeSimpleInterfaceProxy cannot be serialized because
it does not have a parameterless constructor.


Any ideas on how to create such parameterless constructor on the
mocked object? Or is there any other way to make serializing it
possible?

Thanks in advance!

Daniel Cazzulino

unread,
Jan 4, 2011, 9:11:08 AM1/4/11
to moq...@googlegroups.com
I'd suggest a manual mock here. Don't think DynamicProxy will allow that usage....

/kzu

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


2011/1/4 Paweł Tarnik <tar...@gmail.com>

Paweł Tarnik

unread,
Jan 4, 2011, 12:24:27 PM1/4/11
to Moq Discussions
OK, the best workaround I've found is to create a dummy class that
implements an interface and to mock that implementation.
We have to write some code, but all auto mocking goodies are still
available (setup, verification etc).

Now I have another problem:
Is it possible to instantiate mock object manually via
Activator.CreateInstance()?
I don't need it directly, but the class under test is trying to do
such thing with mock object (or, to be precise - with type of a mock
object).

E.g. if I have such class:

public class SimpleClass { }


And then mock it and try to create an instance:

var mock = new Mock<SimpleClass>();
Type mockType = mock.Object.GetType();
Activator.CreateInstance(mockType);

Then I get:

System.MethodAccessException:
Castle.DynamicProxy.StandardInterceptor..ctor()
at Castle.Proxies.SimpleClassProxy..ctor()


Any ideas?

LOBOMINATOR

unread,
Jan 4, 2011, 1:00:12 PM1/4/11
to moq...@googlegroups.com
I would solve this problem with the right design (a - d from preferred to
less preferred/optimal).

a) introduce ICreationFactory which simply does Activator.CreateInstance and
in your simple class just verify that ICreationFactory.Create is called. For
other feature tests of SimpleClass just setup factory mock to return another
mock or make it default value mock

- or -

b) Constructor overload which takes Func<Type, IYourObjectToCreate>. Simple
do in your test () => yourMock.Object.

- or -
c) Move Activator.CreateInstance call into over writable method in your
SimpleClass. Either Subclass in your test or use Moqs class mocking feature
to create a mock of your testee with CallBase = true

- or -

d) Manual approach. Move Activator.CreateInstance call into over writable
method in your SimpleClass.

SimpleClass{

protected virtual IYourObjectToCreate Create(Type typeToCreate) {
return Activator.CreateInstance(typeToCreate);
}
}

TestableSimpleClass {

public Type TypeWhichWasRequestedForCreation { get; private set; }

protected override IYourObjectToCreate Create(Type typeToCreate) {
// do not class base here
this.TypeWhichWasRequestedForCreation = typeToCreate;
}
}
use TestableSimpleClass in your test code

Have fun

-----Ursprüngliche Nachricht-----
Von: moq...@googlegroups.com [mailto:moq...@googlegroups.com] Im Auftrag
von Pawel Tarnik
Gesendet: Dienstag, 4. Januar 2011 18:24
An: Moq Discussions
Betreff: [Moq] Re: How to serialize mocked interface

public class SimpleClass { }

Then I get:

System.MethodAccessException:
Castle.DynamicProxy.StandardInterceptor..ctor()
at Castle.Proxies.SimpleClassProxy..ctor()


Any ideas?

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

Krzysztof Koźmic

unread,
Jan 13, 2011, 12:21:32 AM1/13/11
to Moq Discussions
correct. DP does not support XML serialization, only binary (the
reason being - no one really needed it and it was problematic to
implement right IIRC).

Paweł Tarnik

unread,
Jan 13, 2011, 9:00:58 AM1/13/11
to Moq Discussions
>
> correct. DP does not support XML serialization, only binary (the
> reason being - no one really needed it and it was problematic to
> implement right IIRC).
>

Yeah, I understand that.

To solve my latest issue, I've used a workaround (you may call that
"the right design" ;) ), inspired by Mr Lobominator.
Thanks.
Reply all
Reply to author
Forward
0 new messages