Firstly.... before you read this, I would really like feedback on this series of posts and the ideas it outlines. I wanted to get that request made on the first line as apparently most humans skip the next paragraph when searching for info. So with that out of the way I will outline what this post is really about.
These posts are the result of a bit of a mishmash of ideas that I have been thinking about of late. The project I am currently working is fully
agile, therefore
test driven development plays a key role in the day to day work a developer encounters. We perform
integration testing, interaction testing,
unit testing & business testing as well as a few other kinds of testing during the course of writing functionality. The project has also recently migrated.NET 3.5 and a result we have started to take advantage of some of the languages features such as
LINQ.
When I first heard of LINQ I must admit I was sceptical. I am one of those developers who likes to have a thorough understanding of the architecture prior to implementing it my code base. (Remember VB web classes anyone). I picked up the Pro-LINQ
book from Apress a while back and spent a weekend reading from cover to cover. So before I continue I will clarify my position on these technologies.
LINQ to Objects is superb.
LINQ to XML is just as good.
LINQ to SQL is good but not there yet! (Release 3 Perhaps).
LINQ to Entities (Barge pole and touch come to mind).
So with that said I will try and move onto the focus of these posts. LINQ to Objects has been implemented using .NET 3.5
extension methods. Extension methods allow you to implement instance type methods on existing classes. Even if these classes are sealed or you do not have the source code so you can extend them. So given this new feature it got me thinking about what possible uses there are for extension methods. LINQ uses them primarily on types of IEnumerable
in order to implement query expressions, but I wanted to see if I could use them in a more generic fashion on any type of object.
As I felt I had a solution looking for a problem, I decided to bide my time and wait for the problem to present itself. A couple of weeks ago it did!! As said, we are working on a project which has adopted TDD. One of the issue I find with TDD is that I kept feeling I had to break encapsulation principles in order to increase testability. An internal field on a class would need to be set for a specific test condition to pass or an object deep down in my object graph would need to be configured or mocked in order to allow testing. IOC & dependency injection admittedly can help in this area but are not always the simplest of solutions. So end game is that I want to avoid this wherever possible.
Currently, In order to solve some of these problems, our project has a number of utility classes for accessing private members on a reference types. This only goes so far and can be cumbersome to use. What I would ideally like in my tool kit is the ability to seamlessly drill down an object graph using a familiar syntax. More than that, I want to be able to instantly convert those fields or properties to mock objects prior to running my tests. I want to be able to swap mock frameworks without changing my tests and think more about my test conditions instead of the mocking framework. I want a repeatable pattern.
As a result of this I have started work on a library which will provide a simple LINQ 2
Reflection style syntax which will provide facilities for drilling down into any CLR type and performing a number of tasks ranging from (Reading data, Writing data ,
Mocking , Invocation, monitoring, interception and many other extensible behaviours.).
In part 2 I will start to outline some simple uses of these LINQ to reflection extension methods. For the timing being here is a very simple update statement using the extension methods on a person entity.
DateTime DOB = new DateTime(1950, 1, 1);
//Lets perform an Update on our entity.
person
.Field<string>("_firstName").Update("James")
.Field<string>("_lastName").Update("Brown")
.Field<DateTime>("_dateOfBirth").Update(DOB);