What needs to be done to make DynamicProxy work in Silverlight?

Tweet

Some time ago I sort of complained there's no Mocking Framework available for Silverlight. This has a lot to do with the not being available Castle's DynamicProxy for Silverlight. So I did some analyzing on DynamicProxy if it's possible to make it work under Silverlight.

The Castle.Core project

I did some analyzing by just counting the error's. It's about 130 errors that needs to be solved. Most of those errors are the usage of:

• Serializable
• MarshalByRefObject
• ArrayList
• Hashtable
• ReadOnlyCollectionBase

I think that some of those error's that have to do with the collections can be solved like the missing classes: ArrayList, Hashtable and ReadOnlyCollectionBase.

I'm not sure about things like Serializable and MarshalRefByObject. I don't think we can solve them, they probably need to be omitted, but will this break basic features of the Castle Core?

The Castle.DynamicProxy project

The Castle.DynamicProxy project has a lot more errors that occur, around 210. Although while navigating through the source code I found out that nothing in the namespace Castle.DynamicProxy.Generators.Emitters needs to be changed. So does this say that Reflection.Emit has enough to do everything needed for the Mocking frameworks? Most of the errors are in the usage of:

• Serializable
• ISerializable
• SerializationInfo
• StreamingContext
• MashalByRefObject
• Hashtable
• ArrayList
• CollectionBase
• ReaderWriterLock
• FormatterService

Again some of those usages can be rewritten, but the things about serialization probably won't and what about the ReaderWriterLock and the FormatterService? Those are very internally implemented classes. Maybe it's possible to recode things to work without ReaderWriterLock and the FormatterService.

Conclusion

So there needs to be changed a lot in each of the DynamicProxy libraries about 340 lines. That's a lot I would guess. But what if we would solve all these incompatible lines by removing them sort of? I'm afraid this would leave DynamicProxy sort of handicapped. Maybe it's too much so there won't be any mocking frameworks that can make use of the handicapped DynamicProxy. Maybe it's because I've got too little knowledge on the inner workings of DynamicProxy and mocking frameworks like Moq and Rhino Mocks.

I hope somebody with a lot of knowledge can tell if things like Serializable, MarshalByRefObject and... are really necessary. Maybe the founder of the Castle Project, Hamilton Verissimo can help out.

Thinking about Silverlight and Mocking

Tweet

There are quite some Mocking frameworks available. But sadly no one is ported to Silverlight, yet. I know about the porting of NUnit to Silverlight, but while working on Unit tests for the "Silverlight Networking through Javascript" library I found out there's no Mocking framework yet to support the Silverlight runtime.

I would like to see some support for Silverlight from either Moq or Rhino Mocks. That's because I like the way those Mocking frameworks work. I think they both make use of Castle's DynamicProxy, so that's another thing that first needs to become Silverlight enabled.

I'm sure more people thought about Mocking in a Silverlight runtime but didn't find a solution too. I'm interested if anyone started to port one of the above Mocking frameworks to Silverlight. I'm not even totally sure if it's possible but at least a part of Reflection.Emit exists.

What are anyone's thoughts about Mocking in Silverlight?

Book review: Test Driven by Lasse Koskela

Tweet

Some time ago I did the technical review of the Manning Book Test Driven by Lasse Koskela. The book is available since October 10th.

The book is devided in three rough parts: Part 1, A TDD primer; Part 2,  Applying TDD to specific technologies; Part 3, Building products with acceptance TDD.

Part 1, A TDD primer: This part is about Testing in general and covers refactoring and patterns as well. Everything is written with Test Driven Development in mind. So don't expect all possible refactorings and patterns covered here.

Part 2, Applying TDD to specific technologies: This part covers testing on specific technologies. Where the first part can help people start testing, the second part will help people continue testing even if the more complicated tests need to be written. Specially complex testing on Web components, data access, etc.

Part 3, Building products with acceptance TDD: The last part covers more on acceptance testing. I haven't got any experience with automated acceptance testing but this part covers it quite well.

Although this book has some influence from the Java world almost everything can be applied within other technology worlds as well, like .NET, Ruby and PHP. I like this book and will use it every once in a while to keep myself focused.

Mocking with Rhino Mocks: Expecting a method not to be called

Tweet Mocking with Rhino Mocks: Expecting a method not to be called This morning I thought about trying out some Mocking with Rhino Mocks. First of all I was having some little trouble of testing method's that returned void. Oren Eini suggested somewhere to make use of method chaining, so I changed it to use method chaining. So what's next? Expecting a method not to be called. For example the situation on line 12: I expect the WriteLog method with parameter EventLogEntryType.SuccesAudit not to be called. I think the test I wrote should work.

 1 [Test] 
 2 public void TestInterpretationForAuditFailureNotWorking() 
 3 { 
 4   MockRepository mocks = new MockRepository(); 
 5   ILogWriter eventLogMock = (ILogWriter) mocks.DynamicMock( 
 6                                       typeof (ILogWriter)); 
 7   ILog log = new Log(null, eventLogMock, "MOCK", true, false); 
 8  
 9   Expect.Call(eventLogMock.WriteLog( 
10               EventLogEntryType.FailureAudit, "MOCK", null, null, 0) 
11     ).Return(true); 
12   Expect.Call(eventLogMock.WriteLog( 
13               EventLogEntryType.SuccessAudit, "MOCK", null, null, 0) 
14     ).Return(true).Repeat.Never(); 
15   mocks.ReplayAll(); 
16  
17   log.Audit(Audit.Failure, null, null); 
18   mocks.VerifyAll(); 
19 }

The test actually doesn't work. I get an InvalidOperationException when I call VerifyAll.

System.InvalidOperationException: Can set only a single return value or 
exception to throw or delegate to throw on the same method call.at Rhino.Mocks.Expectations.AbstractExpectation.ActionOnMethodNotSpesified() 
at Rhino.Mocks.Expectations.AbstractExpectation.set_ExceptionToThrow(Exception value) 
at Rhino.Mocks.Impl.MethodOptions.Never() 

Does anyone know how this can be solved? What am I doing wrong? The only thing I want is: Expect a method not to be called. Update: 1 August 2007 After some e-mail contact with Oren he came with the following solution:

12   Expect.Call(eventLogMock.WriteLog( 
13               EventLogEntryType.SuccessAudit, "MOCK", null, null, 0) 
14     ).Return(true).Repeat.Never(); 

The solution mentions not to use Return, because you don't expect anything in return. You expect the method not to be called.