Mock (and Castle.DynamicProxy) accessing internal/private types

[Lionel]

First a big thank you for Mock. Even if a bit harsh to understand its
possibilities (but have I? It's so powerful), it's really a must have
for testing. So thank thank thank!

The application we're testing relies on many assemblies (100+), in
which some interfaces we would like to mock are internal. I'd like to
avoid to use a InternalsVisibleTo attribute each time to allow
Castle.DynamicProject to access them. But why Castle.DynamicProject2
does not accept internal/private types? I suppose it's all working by
reflection, so that should be possible.

Any idea on that subject? If the idea appeals to the Mock team, can
they ask Caste's team to access internal/private members in their
excellent lib?

Regards,

Lionel

[Jonathon Rossi]

Technical reflection reasons aside, if the type isn't exposed to the test project you won't be able to compile your code if you don't have access to the type to pass to the Moq APIs and you won't be able to call methods on the mock object if it was built using a string because Moq would have to give you back a System.Object.

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

--
Jono

[Lionel]

100% exact. To allow unit test assemblies to access to internal types is common practice, but we also try to restrict the number of assemblies declared as friend (kind of "best practice"...).

 

For those looking how to declare Castle DynamicProject (DP) as a friend assembly, remember that DP generates an assembly on the fly (named DynamicProxyGenAssembly2). So you should not use

[assembly: InternalsVisibleTo("Castle.DynamicProxy2")]
but:

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]

 

 

Regards,

Lionel

---

De : moq...@googlegroups.com [mailto:moq...@googlegroups.com] De la part de Jonathon Rossi
Envoyé : dimanche 12 septembre 2010 02:31
À : moq...@googlegroups.com
Objet : Re: [Moq] Mock (and Castle.DynamicProxy) accessing internal/private types

[Mariano Omar Rodriguez]

In fact you need to include the PublicKey of that assembly too, take a look to the last item in the quick start, http://code.google.com/p/moq/wiki/QuickStart (Under the Advanced Features title).

[Krzysztof Koźmic]

Latest DynamicProxy (2.5.1) has a constant defined for that, so that
you don't have to copy/paste the ridiculously long string and write
this instead:

using Castle.Core.Internal;

[assembly:
InternalsVisibleTo(InternalsVisible.ToDynamicProxyGenAssembly2)]
[assembly: InternalsVisibleTo(InternalsVisible.ToCastleCore)]


HTH,
Krzysztof


On Sep 14, 2:20 am, "Mariano Omar Rodriguez" <marian...@gmail.com>
wrote:
> In fact you need to include the PublicKey of that assembly too, take a look to the last item in the quick start,http://code.google.com/p/moq/wiki/QuickStart(Under the Advanced Features title).

>
> From: Lionel
> Sent: Monday, September 13, 2010 3:33 AM
> To: moq...@googlegroups.com
> Subject: RE: [Moq] Mock (and Castle.DynamicProxy) accessing internal/private types
>
> 100% exact. To allow unit test assemblies to access to internal types is common practice, but we also try to restrict the number of assemblies declared as friend (kind of "best practice"...).
>
> For those looking how to declare Castle DynamicProject (DP) as a friend assembly, remember that DP generates an assembly on the fly (named DynamicProxyGenAssembly2). So you should not use
> [assembly: InternalsVisibleTo("Castle.DynamicProxy2")]
> but:
> [assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
>
> Regards,
> Lionel
>

> --------------------------------------------------------------------------------

> De : moq...@googlegroups.com [mailto:moq...@googlegroups.com] De la part de Jonathon Rossi
> Envoyé : dimanche 12 septembre 2010 02:31
> À : moq...@googlegroups.com
> Objet : Re: [Moq] Mock (and Castle.DynamicProxy) accessing internal/private types
>
> Technical reflection reasons aside, if the type isn't exposed to the test project you won't be able to compile your code if you don't have access to the type to pass to the Moq APIs and you won't be able to call methods on the mock object if it was built using a string because Moq would have to give you back a System.Object.
>