May 9th, 2008
Is a same method you would use with NMock2, but with “DynamicProxyGenAssembly2″ in InternalsVisibleTo.
This strange name is a default dynamic assembly name used by Castle.DynamicProxy.
Do not forget that the attribute should be added to the assembly with internal types, not to the tests assembly (obvious, but I got it wrong the first time).
[assembly:InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=002400000480000094000000060200000024000052534 1310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b 3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d926665 4753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb 4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c486 1eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")] // without line-breaks
September 23rd, 2007
One of the places where I am likely to actively use expression trees is testing/mocking.
(I am not the first one to notice this â€” I saw some post on expression tree asserts, but I lost it).
In my day-to-day development I am using NMock2.
Ayende‘s Rhino Mocks may be more convenient, but I do not like the syntax.
I just can’t read “expect call return” â€” my mind wants “expect call returns”.
Also, event support in Rhinos is really cryptic.
(I understand that it may be the only stringless way to express it).
So working on C# 3.0 project, I’ve looked into a stringless experience with NMock2.
What I wanted was to pass a method call expression, to change this:
Expect.Once.On(fs) .Method("GetDescendantDirectories") .With(RootPath) .Will(Return.Value(directories));
Expect.Once .That(() => fs.GetDescendantDirectories(RootPath)) .Will(Return.Value(directories));
Fortunately, it was quite easy to do with extension methods.
I have spent more time figuring better fluent syntax than actually writing it.
But the case where expression trees really shine, I think, is in the possibility to do this:
Expect.Exactly(directory.Files.Count) .That(() => access.IsPublicFile(Any.String)) .Will(Return.Value(true));
I can analyze expression tree and find out that Any.String is not “a string”, but “any string”.
It is also easy to imagine Any.String.Matching(“^whatever”) and so on.
I have not tried to implement it, but I feel that it would be simple as well.
Also, while writing the post, I just got an idea â€” in the world of extenson methods we can do
Expect.Exactly(directory.Files.Count) .That(() => access.IsPublicFile(Any.String)) .Will.Return(true);
without sacrificing extensibility.
“Will” can also be chained if more than one action is needed (however, a delegate would be better for this).
It would be nice to actually add this to NMock2 (as 3.5 branch), but they are using CVS, not SVN.
Also, am I the only one who thinks that SourceForge is slow and has hardly usable (bloated) design?
So if you want the code, you can ask me in comments, but it is primitive indeed.
July 7th, 2007
Yesterday I stumbled into a question of how to mock an internal interface.
The interface is visible in the test assembly due to InternalVisibleTo attribute, but Mockery was unable to create a mock of it.
The very first idea was additional InternalVisibleTo, but I had to find out what assembly name to use.
Since dynamic mocks are actual classes created on-demand for the specified interface, they do not belong to NMock2 assembly.
But they have their own dynamic assembly with consistent name — in case of NMock2 it is “Mocks” (I got it from Reflector).
So I used InternalVisibleTo(“Mocks”) and it actually worked.
I am not sure if it would work with strong names, but, fortunately, I do not need to strong name this project.