Skip to main content

Dynamic Anonymous my experience through out assemblies doing unit tests and more RuntimeBinderException Headache


While at work on a project I was facing a matter that caused me a lot of headache, which is passing dynamics throughout assemblies, after doing a lot of research and investigation like
Should I use dynamics if no then why and how can I compensate it’s flexibility and stuff like that  just to get a profound to wither to use it or not ,
And I found that it is preferred not to use dynamic whenever possible and that because
The overhead it causes on the runtime, in other words the time to identify properties types is not done on compile, it is done on runtime thus the overhead.
Nevertheless the fact that literally we do not know if it is working alright, unless we are at runtime if it is not working for instance we got a property name wrong  then boom exception for sure
BUT
a very convenient guy would say where are your tests that should cover that from happening “just for your info not all of us right tests and not all of us right proper tests”, I would say that is one other reason why we should not use dynamic, because most of us faced this problem when creating tests, The problem is
exception run time binder could not find property x in object y,                                  

 first the reason this happens because when create a test for dynamic return you will most likely will use mocking and other stuff all the guys involved in TDD probably know about it to mock the return of a dynamic, but that is not the problem, the problem  is passing dynamic objects throughout assemblies what happens is in testing run time the dynamic properties do not get resolved by the test runner, the reason why this was happening made me go nuts I was spinning round on why in hell is it not working and I got a bit confused to think that it was a bug in VS or something and there is a bug similar to that reported to Microsoft
and so at first I thought it is a bug and it is reported on this have read a thread about, after long hope I found that me using anonymous type was the reason as they don’t get resolved across assemblies,
So after being in so much trouble I just had to set some rules when using dynamics and that is for the sake of safety and good performance which were:
That you should not use dynamic extensively avoid them whenever possible there are certain situations where you will not be able to completely not use them but at least keep this in mind
You should never pass it through assemblies the reason why this is because, create a concrete class and pass it, that way your tests will not get screwed over a tiny reason like using anonymous.


What drives people towards dynamics and can there be something that can replace it ?
Flexibility the thing about it is that people will always resort to dynamics cause it is easy and removes a lot of headache in configuration or casting, but if something goes wrong, lets say no good deed is left unpunished, you will probably get things missed up.
Another thing is contracts usually when creating Interfaces all you have to put as return of a method is dynamic it does not matter if it was a class instance of your own, a POCO object, a collection of any type of objects or anything this contract will be implemented perfectly.
For the flexibility part I don’t think that can be replaced but for instance the Interface,  it is a very common best practice to put all your interfaces “Contracts” in one single independent  assembly  so you can’t use any custom type or class as a return, that can easly accomplished by dynamics but it can be also done using generics,

The use of the magical <> instead of dynamics if it returns a list use  IList and that should do the trick for you all the way.
Here is a link where I created a generic repository interface
To illustrate this with examples here is:
A sample test would normally fail cause of exception runtime binder exception

 so the test simply check for a return of a function that returns a dynamic object and checks for its return, once run at run time, a binder exception  will be thrown in the Assert statement as the props cannot be resolved
So my solution for this problem was pretty simple, I created a concrete class to return instead of a dynamic so whenever possible I did not have my methods returning dynamics so that way I lost the headache
For Generic Interface I only used generics here are some samples
The generic repository interface

Another one would be as following

The issue would be how to generalize the return of the methods in the interface or contract, I have two situations one is when returning a custom object and the second when returning a collection of customer objects, each one I have demonstrated how to return them in a generic way using IList for collection and The <T>.

That’s it hope it was of a help  to you guys.
Thanks for reading.

Comments

Popular posts from this blog

(AsyncWebClient) Async Webclient for windows phone 8

Using windows phone web client is pretty common but the thing is you can not use it using Async -> Await mechanism so i used threading to create an async functionality for The Download string and upload string methods here is the code below // Comment public class AsyncWebClient { public Task DownloadString(Uri uri) { var task = new TaskCompletionSource(); try { var client = new WebClient(); client.DownloadStringCompleted += (s, e) => { task.SetResult(e.Result); }; client.DownloadStringAsync(uri); } catch (Exception ex) { task.SetException(ex); } return task.Task; } public Task UploadString(Uri uri, string content) { var task = new TaskCompletionSource(); try { var client…

RuntimeBinderException cannot resolver property in Unit Test in case of dynamic return.. Solved

Xamarin UI Tests – Deep dive Part 1

IntroAs the title may describe this is the first of the series of articles that will cover the UI Test of Xamarin in a deep dive, we will start simple and then dig deeper as we go. Since this is very well the first of the series, it will mostly cover up the architecture and the testing technique that Xamarin UI Tests uses.

The Technology
Xamarin UI Test is an automation testing framework similar to selenium, Watir, Watin (.net), Robot and Sikuli, if you have used BDD (Behavioral Driven Development) or a more advanced TDD (Test Driven Development) approach at least you must have come across one of these frameworks, and in that perspective comes Xamarin UI Testing as an automation framework designed specifically for Xamarin Automation testing, For starter Xamarin UI Tests was not build from scratch, instead it was built on top of another UI Automation testing framework that is targeting android and iOS sepecifically which is Calabash, I have to say that this choice was made wisely as of n…