If you are using extension methods as a way to achieve more language oriented programming, there are lots of times you will want to be able to run extension methods against an anonymous method, but you will first have to close it to a well known delegate type before it is allowed. Here is a useful method if you want the starting point to be an anonymous method created on the fly:

Develop With Passion!

During class last week someone had written a piece of code right near the end of the last evening and I committed to showing them a potential refactoring that could be used. Here is the piece of code in question:

The code is not really complicated. The messiness comes from the fact that an index needs to be maintained so that it can be used to lookup into another equally sized collection that is not the target of the iteration. There are obviously lots of ways to solve this, but I thought "why not just flatten the two collections into a single collection which eliminates the need for the index. Here is the resulting code that was produced:

The union method is a new extension method that will take 2 disparate collections of the same size and combine them into a singular collection of Tuple<T,U> types. I created a simple Tuple class as nothing more than as an immutable parameter object. Here is the resulting code for it (very simple):

Finally the code that pulls it all together is here in the extension method that does the heavy lifting:

This method hides the details of the indexer into a utility method that can be used anywhere where 2 sets of disparate items of the same length need to be combined into a singular set.

Thoughts?

Develop With Passion!!

There are some big, big changes coming this year that will revolve around how Nothin' but .Net promotes the cause of education. Registration for courses started a couple of weeks ago and I am excited about the potential that this year brings for people who are going to be registering.

After a couple of tweets in the twittersphere, and a great recommendation by Scott; I realized that there were a couple of things that I could do this year to promote the cause of education and make the training a little more accessible. This post outlines the high level plans that are going to be implemented as soon as possible.

In no particular order the items are:

NBDN Scholarship Program
There are lots of people out there who are desperately wanting to get involved with some form of high quality training. Unfortunately, there are also a lot of people who just do not have the resources/support to undertake the financial weight of the course. To that end, this year for each class there is going to be a scholarship issued to one person who will have their complete course tuition wavered. This does not include airfare and accommodations, just the ticket price for a seat in the class. One of the things we are deciding right now is how to go about deciding the format for how this process should work. How do we pick from a potential pool of people who may want to attend the course. Based on the contest I ran last year, it may not be that difficult as in spite of all of the freebies that were being given out, there were very few actual "submissions". If you have any suggestions on how I should structure the "submission" process it would be greatly appreciated. Right now I am leaning in the direction of having people submit stories that describe why they should be awarded the scholarship.

NBDN Course Primer
In the cities where I can coordinate this (and get the timing right), there is going to be a free 1 day primer course that will be open to the public so that they can come and discuss, code, and get a feel for what the scope of the course will entail. My plan for the primer course is to spend the day working through concepts that I feel are prerequisite knowledge, make developers more productive in general, as well as to dive into some code, patterns, and concepts that people should be familiar with (especially if they want to take the course at a later time). Like the course, there will be limited seating (16-20 max), and people will be expected to come with open minds ready to challenge, learn, and have fun. One bonus (in the cities where there is participation) will be the opportunity to work and share discussions with past students (from the local area) who can speak openly and honestly about their experience with the course. In the primer course day people will get exposure to the following :

• Build automation with rake/powershell
• Context/Specification style testing
• Back to advanced basics with core .Net
• Fundamental Design Principles

Although it is termed as a primer, the goal of the day is to have people leave with their head stuffed full of new ideas and approaches they may not already be familiar with. The reason for the size of the class is to enable as much rich communication as possible, which is very difficult to do in large class sizes. I expect these primers to generate a lot of questions!!

DNRTv
After a great discussion with Carl, we have decided to set some time aside in May to record 2 full days worth of training material. Again, the goal with these videos is to serve as primers for people to get exposed to many concepts that can be instrumental in making them more productive developers. These videos will be extremely code intensive, and should leave people with a greater awareness of tools and techniques they may not already be familiar with. The scope and material that will be covered in these two days is yet to be determined, though my hope is that these videos will give people a great deep introduction to a host of topics.

As you can see, there are lots of plans that are in store this year and I am excited about what the Lord has in store for myself and all of the people I hope to interact with!!

Develop With Passion!!

I have not changed my build script for my current project for a little while. As the project started to get bigger I started to notice a significant slowdown in building from my build script. I stopped to take a look at my script this morning and smacked my head when I saw what was going on. It read like the following:

$result = MSBuild.exe "$base_dir\solution.sln" /t:Rebuild /p:Configuration=Debug

A quick change to the following and it was all good:

$result = MSBuild.exe "$base_dir\solution.sln" /t:Clean /t:Build /p:Configuration=Debug

Micro optimization is where its at!!

Develop With Passion!!

I am currently working on a large winforms application (most likely the last winforms app before I make the transition to WPF). I am writing the application in a top down fashion, which means I drive out the tests for the presenters, and then move down through the corresponding layers to get a good vertical slice of functionality. When it comes to the development of the user interface I am using a command based UI to allow me to easily drive the testing of the screens easily from a unit test. One thing that I often need to do, is cause a UI component to trigger one of its own events to see if the command in question will be triggered. In order to allow for a bit of “guidance” I wrote a class that allows me to quickly trigger events on UI components. The following code snippet shows a usage:

I am making use of an expression tree to determine which event I want the target control to raise. This is easily done because most (almost all) UI components in both the .Net framework and 3rd party Winforms libraries follow a convention of having a method named “OnEventName” which is usually a protected method that the control itself can call when it wants to raise its event. The EventTrigger class lives in my test utilities and for my current application I have a set of Events classes which correspond to some of the third party, and raw .net, control I want to raise events on, here is a trimmed down section of one of the events class:

Again, this class lives in my test utility folder and it contains interfaces specific to control types that I want to raise events on. For each control interface, I will place the events (as needed) that I need to be able to trigger from my unit tests. There are multiple ways to get the correct method signature on these interface methods, I can use the Object Browser, Reflector, or ReSharper can generate them!! The point is, the interface contains a public method that is the identical signature for a corresponding protected method on the target control. This is really to help get intellisense about the event I want to raise along with the arguments to the method itself. This works with all component frameworks as their EventArgs classes are always made public as to be able to be consumed by the components that will be hosting them.

Let’s get to the interesting part of this. I mentioned earlier that I am an expression tree to ultimately raise the event. Let's take a look at the trigger_event method signature to get a little understanding of what it is doing:

Notice I am making use of the IEventTarget interface to basically simply constrain the incoming expression to be one based on one of the interfaces that lives in the “Events” class. The first argument “Expression<Action<Target>> is an expression representing the code. The target argument is the actual control to raise the event on. Here is the entire body of the trigger_event method:

This is test utility code, so I am able to make a lot of assumptions about how I am going to be consuming and using it. For starters I know that the ExpressionTree coming is is going to represent a MethodCallExpression. This post is only a small intro into the amazing concept of expression trees, if they are not something you are comfortable with, there is no time like the present to start playing around with them.

With a MethodCallExpression I have access to the MethodInfo object that contains information about the target method to call (this allows me to reflectively match upto the protected method on the target I want to raise the event on:

Once I have the actual method to invoke, it still needs to be invoked with the correct arguments:

The act of getting the arguments is the interesting part to this code (and a little gentle introduction to the world of ExpressionTrees for those of you who are not using them yet). The following line:

method_call_expression.Arguments is actually a collection of Expressions also. If you look back at the line of code that is using this the original trigger method, we’ll decompose it so that you can get a better idea of the expression tree created to represent the call to the event:

• MethodCallExpression [x.OnKeyPress(
  • NewExpression[new KeyPressEventArgs(
    • ConstantExpression(‘A’)
  • )
• )

Expression tree are “tree based structures. This simple line of code actually constructs an ExpressionTree that consists of a:

• MethodCallExpression
  • NewExpression
    • ConstantExpression

Here is the complete code for the get_parameters_from method:

This method iterates over each Expression in the incoming set and attempts to expand it to an actual object value. The can_handle method simply makes use of an existing dictionary that has been populated at startup with handlers that know how to evaluate the appropriate Expression:

The get_value_from_evaluating(expression) method is very simple, it just look into the dictionary using the NodeType of the current expression, and invokes the expression handler against the expression so that it can be evaluated:

Lets start by looking at the simplest one of them all, the method that evaluates a ConstantExpression:

This method explicitly casts the incoming Expression to a ConstantExpression and then returns the expressions value. In our current example, that value will be the char ‘A’.

We’ll finish up by looking at the most involved one:

In the second line we are actually evaluating each of the constructor arguments expressions one at a time and having them also evaluated by the get_value_from_evaluating method. Because of the nested nature of expression trees, depending on the type of Expression that was passed in, this handles recursive traversal of the expression.

Once all of the arguments to the constructor have been evaluated, we can then invoke the expressions Constructor (which is a ConstructorInfo) to create the item. In our example here, it will cause the creation of a new KeyPressEventsArgs with the character of ‘A’ (the character was evaluated using the ConstantExpression we discussed earlier).

When it comes to testing a new control I can just create a new nested interface in my Events class, add public versions of the protected methods that I want to invoke (along with the correct arguments) and then I’m off to the races!!

Develop With Passion

As the current project I am on is getting fairly large now, I just recently switched around the way I organize my tests. Here is a sample concern pulled from a main class in my application (smart client based):

Notice how at the top I am now creating a container class which is named {SUT}specs:

All of the concerns for the ApplicationController will be housed inside this class. From an organizational perspective I can now have a superclass for all of my concerns for a particular SUT named concern:

Before, I would place my concerns directly at the root of the file (not nested inside a container class), this meant that when I went to derive a concern from a base concern, I would have to filter through a big ReSharper list of all of the base test classes in the solution that started with the word concern. Because I was following a convention of “concern_for_[sut]”, I would see more than I wanted. Now when I am inside of a container class and am writing a concern that I want to derive from its parent concern,typing con followed by CTRL-SPACE will only give me a very small set of options. I also don’t need to come up with a fancy name for the initial concern superclass. I can just call it concern. Each *Specs file in my current application follows this convention, and each one has an initial superclass named concern. You don’t need the superclass, I just find it a convenient place to put fields etc that can often crowd up the test, common results etc.

Develop With Passion!!

If you recall from the last post on this topic one of the ways you can record an observation is by simply doing this:

In addition to be able to define observations using traditional attributes. You can now also define observations by using blocks (like the rest of the code uses). So the following observation is identical to the one above:

Because all of this is backed by MBUnit. You can start integrating this into your existing MbUnit test suites with no change required. MBUnit GUI, and Console pick them up with no problem. TestDriven.Net can even run them. You can mix and match traditional attribute based observations and block style observations in the same test:

The only issue with TD.Net right now, is that you can’t pick a single “it” block to run in a fixture. If you put the cursor on an “it” block and tell TD.Net to run test, it will run all of the “it” blocks in that fixture. If you are using a traditional attribute based Observation block this is not a problem.

If people are interested in how I rolled out this feature, please respond with comments and I will get another post out!!

Develop With Passion!!

The other day I placed a library up on assembla that I use as a place to store my current set of conventions on writing unit tests. My current flavour of testing focuses on the use of BDD to emphasize context and behaviour of a particular SUT (System under test) that I am exercising.

This post is not about detailing my current thinking on BDD, more to demonstrate some ways that you can use the very small framework in conjunction with MBUnit to remove a lot of cruft from your tests. To that end, the following are some sample tests written to demonstrate different aspects of the library:

1) Adding two numbers (without a because block):

Notice that the class simply inherits from a class named  observations_for_a_static_sut. This is the base class you will use when you are either testing a static class, or (as in this case) you are simply writing a quick inline test.

2) Adding two numbers with a because block (the because block is meant to focus your eyes to the actual behaviour you are exercising:

The behaviour being exercises is placed inside of a anonymous method block assigned to a delegate type (because). It is also important to note that the field is static.

Let’s look at a slightly more involved test that has some dependencies, a factory method for the system under test, etc.  Here is the start:

Let’s start by taking a look at the context block:

In this block I define all of the dependencies that are going to come into play during the test. The “an” method, is a generic method that lives on the base class, which basically creates a mock of the contract in question. It carries on to setup return values for method calls that will be leveraged during the course of the SUT doing its work. Unfortunately, it is hard to identify which mocks are direct dependencies of the sut and which are collaborators. It is only when you look at the factory method for the system under test:

Here it is evident that the direct dependency of the DatabaseGateway is the connection_factory (IDatabaseConnectionFactory). The because block highlights the behaviour being tested:

The force_traversal method is a utility method that forces the traversal of an enumerable. It is necessary as the implementation of the method under test uses deferred execution by nature of leveraging the yield keyword and returning an IEnumerable. Here is the implementation of the class under test:

Let’s now show the exact same test written with the minimum amount of plumbing code that is necessary:

The factory method has been removed along with the fields to reference the dependencies that come into play. For readability, I think this approach loses out, so this last way is the way I would finish up with:

This tests reintroduces the fields to store the mocks. It still removes the factory method, and it uses the following two different methods:

• the_dependency<T>
• an<T>

to differentiate between a constructor depedency and a mock that happens to come into play while collaborating with that dependency.

There are lots of other things you can do, and I will post more examples as requests come in!!

Develop With Passion!!

We left off in part 1 with an example of a test written using my current style and I finished off outlining the skeleton for one of the base classes that shields the actual Concern classes from a lot of noisy test related nomenclature.

In this post I am going to break down the responsibilities of the “an_observations_basic_set_of_behaviours” class. For a quick reminder, here is the skeleton outline of the class:

Let’s start off by discussing the fields:

static protected IDictionary<Type, object> dependencies;

• This field will be used to store a reference to the exception that the sut threw while it performed its work. Is used in conjunction with the doing() method (more on that later).

• I am going to revisit this field when we discuss the doing() method

That takes care of the first set of fields, lets move on to a method that should look very familiar to MbUnit/NUnit people:

This is a traditional MbUnit setup method. Because it is decorated with the SetUp attribute, all of the code in this method will get run once before each observation (test). Essentially this method is used to reset stateful fields, this is not that interesting. The guts of setup happen in the following method:

In this base class the initialize_the_sut method has an empty implementation. The prepare_to_make_an_observation method leverages a hook method (initialize_the_sut) that can be leveraged (it will be by an_observation_for_an_instance_sut). In the base class, it is a virtual method with no implementation. As you can see, this method is responsibility for performing the following actions before an observation can be made:

• Establishing the context (run_action<context>())
• Initializing the SUT
• Invoking the behaviour under test (run_action<because>())

Again this is a small little method that basically serves as a driver for prepping the way to be able to make observations. By the time we actually enter an observation in our actual fixtures, the SUT has already performed its work!!

Now I am sure you are wondering what the deal is with the run_action method? Here is the signature for the run_action method:

This method is a generic method that accepts a delegate type as its generic argument. Again this is a convention that is understood by the naming of the generic parameter. You can’t place constraints on a generic method that constrain the Generic argument to be assignable from a delegate (of course, you can do this with a guard clause). Here are the different delegate signatures that I defined for use in the test-harnesses:

You may be wondering why I did not just use the plain old action delegate as opposed to creating discrete delegate types. This is so the driver class (this one we are examining) has a clearer way of differentiation between the different delegates. Without the named delegate types, I would have to resort to following a convention for the name I assigned to a field for an Action delegate (messy, messy).

Here is the full implementation of the run_action method:

Once again, this method is pretty simple as it is really delegating its responsibility to whatever gets created by the build_command_chain method. So lets dive into the full body of this method, as this is really where the majority of the work is being done:

So what is going on here. Take a look at this test one more time as it will give you a good visual as to what is going on:

I chose not to also put in this Concerns base class, the only important thing to remember about the “concern_for_mapping_step” is that it also has its own context block :

It is important to remember that the “an_observations_basic_set_of_behaviours” class is the test driver. Here is the inheritance hierarchy for this current test fixture:

• an_observations_basic_set_of_behaviours
  • observations_for_an_instance_sut
    • obsevations_for_a_sut_with_a_contract
      • concern_for_mapping_step
        • when_an_expression_mapping_step_is_told_to_run

At any point in the chain (starting from the top, working down) each level could have its own context to run. The run_action method is responsible for walking the inheritance hierarchy of a particular concern and building a chain of “commands” for a particular delegate type. Once the command chain has been build, the chain can be executed in the right order (from top to bottom) to ensure that any prior context in a base class has been established before a subclass runs. If you are already thinking, could he not have done the same thing with abstract/virtual methods. Yes. When I initially started down that route, I kept getting stung by forgetting to call back into the base method. By now having to worry about calling the base method prior to doing your own work, you as a developer can just focus on the context that is applicable to a particular test. You can do this, as the driver class is responsible for ensuring blocks run in the order they are supposed to run. Without the driver class, all the fields that have lambdas assigned to them would be useless as they are just sitting there waiting to be invoked.

At the end of the while loop in the build_command_chain method there will be a stack (I chose stack as it is a LIFO structure, which is perfect for walking a class hierarchy, as when the last item is added – the base class, I can just start popping items off and they will be in the right order, ending with the ultimate test class itself). The stack itself is being used to store a set of ICommand implementations. Here is the ICommand interface:

This is a pretty stock interface that I have used for years. The uses are endless!! How does the loop know when to end? What is with the following method?:

The field current_class is of type Type. The is_a_concern_type method is a local extension method that has the following implementation:

This method just adds a bit of readability (from the point of usage, which is a huge bonus of extension methods) and ensures that we wont worry about putting anything that is not either a derivative of an_observations_set_of_basic_behaviours or the an_observations_set_of_basic_behaviours type itself on the stack (it will always be the top item on the stack at the end of the traversal).

So lets explore the line that does the grunt work:

Keep in mind that the actions field is a stack of ICommand. It stands to reason that the DelegateFieldInvocation class is an ICommand implementation. Which it is. The DelegateFieldInvocation class takes in its constuctor a delegate type to scour for, an instance to act against (always this), and finally the particular type to reflect against (this will change as we continue to walk up the inheritance hierarchy). Here is the implementation of the DelegateFieldInvocation:

All this command does in its run implementation is scour all of the fields in the “current_type” and filters them to look for only fields of the certain delegate type being searched for. Once the particular delegate type is found, we get the value of the field using the instance:

downcast_to is just a utility extension method to do casting. At this point we have an actual reference to the delegate. With that, because we know (again by convention) that all of the delegate types we are working with are void with no arguments, they can just be invoked by using the DynamicInvoke method that lives on the delegate class. Again, the beauty of the command pattern allows this command to be queued up with all the information that it needs, and then it can simply perform it when it is told to run.

Of course, the build_command_chain ends with this line:

All that this method does is return a Composite of commands that when told to run, will run each of the commands that it is composed with (we’ll dive into that at a later date). So back up in the run_action method:

It should now be clear to see that the run() method is invoked on the Composite, that will cause all of the commands to run in sequence. In the case of run_action<context> it will cause a Composite command to be built that is composed of commands to run “context” delegates from the Grandparent down to the actual Concern itself.

For clarification, look again at how the run_action method is used:

The other calls to run action simply walk down the hierarchy invoking the appropriate delegate fields that may or may not be present in the actual test classes. The because block is the behaviour we are invoking of our system under test. In the case of the test we first examined:

For the design pattern aware, you will have already realized that the prepare_to_make_an_observation method (along with the use of delegate fields that can be defined at any level of the hierarchy) is just a specialization of the template method pattern, the main difference being that subclasses do not provide their behaviour by overriding abstract methods, rather they just simply have to define fields of a certain delegate type, that contain the code that will be invoked dynamically by the base class using reflection!!

That is enough for now, we’ll carry on the drilldown in the next part!!

Develop With Passion!!

In the ongoing goal of “Competing against yourself daily” I have changed many things about my coding style over this past year. One of the areas that has been most affected by all of this is how I organize and write tests for the systems I am building.

Here is an example of a test that I wrote for something called a MappingStep:

    public abstract class concern_for_mapping_step : observations_for_a_sut_with_a_contract<IMappingStep<SomeSourceObject, SomeDestinationObject>,
                                                         MappingStep<SomeSourceObject, SomeDestinationObject, string>>
    {
        static protected ITargetAction<SomeDestinationObject, string> target_action;
        static protected ISourceEvaluator<SomeSourceObject, string> source_evaluator;

        context c = () =>
        {
            target_action = the_dependency<ITargetAction<SomeDestinationObject, string>>();
            source_evaluator = the_dependency<ISourceEvaluator<SomeSourceObject, string>>();
        };
    }

    [Concern(typeof (MappingStep<,,>))]
    public class when_an_expression_mapping_step_is_told_to_run :
        concern_for_mapping_step

    {
        static SomeSourceObject item;
        static SomeDestinationObject destination;
        static string name;

        context c = () =>
        {
            item = new SomeSourceObject();
            name = "JP";
            destination = new SomeDestinationObject();

            source_evaluator.Stub(x => x.evaluate_against(item)).Return(name);
        };

        because b = () => sut.map(item, destination);

        [Observation]
        public void should_run_the_target_evaluator_passing_it_the_information_retrieved_from_evaluating_the_source()
        {
            target_action.was_told_to(x => x.act_against(destination, name));
        }
    }

First thing to notice is a convention I have started using when it comes to writing tests. I create a base class named concern_for_[name_of_system_under_test]. You will also see that all of the fields in the test classes are static and not instance. The 2 fields in the base concern_for_mapping_step class are there to hold references to dependencies of the system under test. I don’t need to have them there as they are accessible using a helper method on the base test class (more about the base test class hierarchy in a minute), I just like to have them as I find it a bit more readable than calling methods to access the dependencies of the system under test ex:

• I prefer referring to a field named: target_action as opposed to repeatedly having to call a method such as:
  • Mock<ITargetAction<SomeDestinationObject,string>> / the_dependency<ITargetAction<SomeDestinationObject,string>> (of course, in this example, the generic signatures emphasize the issue even more!!!)

Second thing to notice is the use of a field named c which is of a delegate type named context. Here is the definition for the context delegate type:

    public delegate void context();

Nothing all that special about it. This field will get used back up in the base test class to “establish the context for the test to run” much like a traditional setup method would / constructor if you are using xUnit.

If we focus our attention now on the “when_an_expression_mapping_step_is_told_to_run’ class, you will see that it inherits from the base concern class. The base concern class will be used to hide fields/extra noise that would otherwise pollute the test. You will see that this test also has its own context block. Context blocks are applied recursively from the top of the hierarchy down, this ensures that any contexts in base classes will always run first. In the past I would use overriden methods to accomplish this, but then you had to deal with making sure to call the base “establish_context” method, and if you forgot you could have tests fail because of a silly omission. By adhering to a convention of placing scaffolding in a context block, the “framework” takes care of ensuring that contexts are run in the correct order.

The following block:

 because b = () => sut.map(item, destination);

focuses our attention to what behaviour of the system under test we are testing (in the particular context). You will notice that I use the name of the class to embody both action and context. Of course, in this particular test I am focusing on a happy day scenario. An example of testing in another context could be a test fixture named:

• when_a_mapping_step_is_told_to_map_from_an_invalid_source

This name implies context. In the first test I am just testing the behaviour of mapping. In the second test (which is a different context), I am testing how the sut behaves when it is provided invalid data. One of the things that is hard to see from this example is that one context (test fixture) could have several observations (assertions). In this current example there is only 1 observation being made.

Notice that the because block, like the context block is a field of a simple delegate type (another void delegate type). This means that the code does not execute as it is just an anonymous method of certain delegate type being assigned to a field of a matching delegate type.

Finally observations are made. Notice the use of the Observation attribute. Inside an observation (Test) I will make logical assertions against either the system under test, the dependencies, or the outputs of the method under test. It is best to try to stick to one logical assertion (keeping in mind that 2 actual assertions can be part of 1 logical assertion) per observation. This is why you will often see a single Context (TestFixture) with multiple Observations.

One of the things that you may have missed is the fact that the System Under Test is never instantiated. This is also taken care of in a base class. I have the ability to override the creation of the system under test, but for most tests, letting the SUT be created for me saves a couple of lines of code, and allows me to not have to change things as more dependencies get added.

So how does all of this work? Currently all of this is coded to run against MBUnit 2.5. I have a project called jpboodhoo.commons.bdd (part of jpboodhoo.commons) where I place all of the plumbing code to make all of this work. Here is a snapshot of the project:

This is one of those utility type projects that got harvested over time as I saw patterns start to emerge. Under the concern folder there are 4 main classes:

In my projects I derive from either one of the following 3:

• observations_for_a_static_sut
• observations_for_a_sut_with_a_contract
• observations_for_a_sut_without_a_contract

Those 3 base classes cover the range of classes I may want to write tests against. I am hoping that the naming of the classes is pretty self explanatory. Here are the definitions for each of the above 3 classes:

    public abstract class observations_for_a_static_sut : an_observations_set_of_basic_behaviours
    {
    }

This one is the most basic, it simply inherits from “an_observations_set_of_basic_behaviours”. I derive from this class when I am testing static classes. The other 2 are equally as simple with a little twist:

    public abstract class observations_for_a_sut_with_a_contract<Contract, ClassUnderTest> : observations_for_an_instance_sut<Contract, ClassUnderTest>
        where ClassUnderTest : Contract
    {
    }

I derive from this class when I want to write tests against a class, but code the tests against an interface of the class, and not the class itself. Here the term interface/contract applies to either a C# interface, or a class that the ClassUnderTest inherits from (usually an abstract class). The final base class (that I can choose to derive from) is very similar:

    public abstract class observations_for_a_sut_without_a_contract<SystemUnderTest> : observations_for_an_instance_sut<SystemUnderTest, SystemUnderTest>
    {
    }

Notice how this class derives from the same class as the previous class, except that it uses the same type for providing the generic arguments to the “observations_for_an_instance_sut”

Again, the 3 classes that I have just covered are there to introduce a convention for people (right now just me) to follow when they are writing their own tests classes. The naming of the 3 makes it pretty simple( I think) to figure out which one you would start with.

With those 3 covered it really leaves the 2 “big ones” that hide a lot of plumbing and MBUnit specific details. Let’s start by taking a look at the skeleton for the “an_observations_set_of_basic_behaviours”:

    [Observations]
    public abstract class an_observations_set_of_basic_behaviours
    {
        static protected IDictionary<Type, object> dependencies;
        static Exception exception_thrown_while_sut_performed_its_work;
        static protected Action behaviour_of_the_sut;

        [SetUp]
        public void setup() { }

        [TearDown]
        public void tear_down() { }

        void do_setup() { }

        after_each_observation a = () => dependencies.Clear();

        ICommand build_command_chain<DelegateType>() { }

        void run_action<DelegateType>() { }

        protected virtual void initialize_system_under_test() { }

        static public void doing(Action action) { }

        static protected Exception exception_thrown_by_the_sut { }

        static Exception get_exception_throw_by(Action action_that_should_be_taken_by_the_sut) { }

        static protected object an(Type type) { }

        static protected InterfaceType an<InterfaceType>() where InterfaceType : class { }
    }

This is just the interface (we’ll dive into implementation of each method in time!!). Let’s break it down step by step. First thing you should see is the use of the Observations attribute on the class itself. This is basically just an alternative to the TestFixtureAttribute (thanks go to Albert Weinert for suggesting this). Here is the code:

    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
    public class ObservationsAttribute : TestFixturePatternAttribute
    {
        public ObservationsAttribute(string description) : base(description)
        {
        }

        public ObservationsAttribute()
        {
        }

        public override IRun GetRun()
        {
            var run = new SequenceRun();
            run.Runs.Add(new OptionalMethodRun(typeof (SetUpAttribute), false));
            run.Runs.Add(new MethodRun(typeof (ObservationAttribute), true, true));
            run.Runs.Add(new OptionalMethodRun(typeof (TearDownAttribute), false));
            return run;
        }
    }

The main thing you should get out of this is that the GetRun method tells MbUnit to look for methods that are decorated with the ObservationAttribute, and to treat them as tests. The ObservationAttribute is really simple:

    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
    public class ObservationAttribute : TestPatternAttribute
    {
    }

You have already seen this attribute used on the test earlier. The thing that should be immediately apparent about the “an_observations_basic_set_of_behaviours” class is that it is there to shield the rest of the test code from the details of whatever xUnit framework you are targeting (in this case, MBUnit).

Tomorrow I’ll continue by breaking down the responsibilities of this class in a piece meal fashion.

Develop With Passion!!

The title is definitely a mouthful!!

A project a year ago (yep, I’m quite behind on the technical blogging front) required the need for Excel generation and formatting. Unlike other Excel generation tasks I had done in the past, this particular task called for generation of tabbed workbooks, with graphs, fancy formatting etc. Much more involved than the trivial stuff I had typically done with excel in the past.

Applying formatting to elements in a tree is a perfect job for the Visitor pattern!! Of course, different types of formatting need to be applied to different cells, some cells need multiple types of formatting applied to them. Composite pattern can come to the rescue here. How can we filter out different types of formatting to certain cells / range of cells? The Specification pattern can come in handy here.

The project resulted in the creation of a fairly flexible excel formatting engine (that has been run against 3rd party excel frameworks SpreadSheetGear, and OfficeWriter).

Here is the interface for a cell visitor:

    public interface ICellVisitor
    {
        void visit(IRange cell);
    }

And here is the implementation for the composite visitor:

    public class CompositeCellVisitor : ICellVisitor
    {
        private IList<ICellVisitor> all_visitors;


        public CompositeCellVisitor()
        {
            all_visitors = new List<ICellVisitor>();
        }

        public void add(ICellVisitor visitor)
        {
            all_visitors.Add(visitor);
        }

        public void add_all(IEnumerable<ICellVisitor> visitors)
        {
            foreach (var visitor in visitors) add(visitor);
        }


        public void visit(IRange cell)
        {
            foreach (var visitor in all_visitors) visitor.visit(cell);
        }
    }

As you can see, a composite basically implements the same interface as the things it is being composed of and it simply (for the most part) does its job by delegating to each of its leaf items to do their jobs. In this case, each visitor is told to visit a cell. This means that when an iterator for a spreadsheet (which essentially makes sure to walk over each cell in the spreadsheet) walks to a certain cell, it can then tell the CompositeVisitor to visit the cell. Because the composite is composed of all the possible visitors that can visit a cell, you only need to pass through the spreadsheet once to apply all formatting.

Here are the names of some of the formatting that can be done:

• ApplyAllCellBorders
• AutoFitCellWidth
• BoldFont
• ChangeFontSize
• CustomFormat
• FormatBackColor

Here is the implementation of one of the visitors:

    public class FormatBackColor : ICellVisitor
    {
        private Color color;


        public FormatBackColor(Color color)
        {
            this.color = color;
        }

        public void visit(IRange cell)
        {
            cell.Interior.Color = color;
        }
    }

As you see, the visitor is only responsible for a single discrete action. It has no knowledge as to whether or not it should actually apply itself against a cell, it just goes ahead and applies itself. This would obviously cause problems as there needs to be a way to allow a Visitor to visit/not visit a cell, without necessarily giving the visit the extra responsibility of making that determination. To accomodate this I separated responsibilities (matching/visiting) by “favouring composition” here is a class that was created to solve this problem in an SRP fashion:

    public class ConstrainedCellVisitor : ICellVisitor
    {
        private ICellVisitor cell_visitor;
        private ISpecification<IRange> constraint;

        public ConstrainedCellVisitor(ICellVisitor cell_visitor, ISpecification<IRange> constraint)
        {
            this.cell_visitor = cell_visitor;
            this.constraint = constraint;
        }

        public void visit(IRange cell)
        {
            if (constraint.is_satisfied_by(cell)) cell_visitor.visit(cell);
        }
    }

The ConstrainedCellVisitor is composed of a raw visitor (that will perform an action against the cell) as well as the specification that will determine whether the cell in questions meets the criteria to be visited with the actual concrete formatting visitor.

The specification interface is something I am sure you have seen me use before (lots of usages, different contexts):

    public interface ISpecification<T>
    {
        bool is_satisfied_by(T item);
    }

 
  

All that is needed to finish it off is a very simple configuration api to configure visitors with specifications. Here is one example of a line that builds a visitor and a specification:

yield return new ConstrainedCellVisitor(
                new ChangeFontSize(8),
                Cell.occurs_between_columns(3, 8)
                     .and(Cell.occurs_after_row(5))
                     .or(Cell.is_named("P3")));
 
 

With this model, the ability to add new formatting needs was as simple as adding a new visitor that was only concerned with a specific formatting. This allowed for the incremental growth of formatting visitors as the report demanded it.

This is just one example of where using the power of composition and a couple of “seemingly” simple patterns, can yield results that are extremely extensible results. IMHO the Command and Visitor patterns are 2 of the most powerful and highly underused design patterns a developer has in their toolkit (of course, like with any design pattern, you need to use them wisely).

I was in the middle of the last Nothin But .Net class (more on that in a later post) and I started playing around with a slightly different way to write unit tests (inspired by the look of MSpec). It was cool to build it/demo it/ and use it in front of the class. Here is some sample code written using the new style:

    [Concern(typeof (ShoppingCart))]
    public class when_a_bag_of_ruffles_chips_is_added_to : a_shopping_cart_with_a_can_of_pepsi_in_it
    {
        static IShoppingCartItem an_item_for_a_bag_of_ruffles;
        static IProduct a_bag_of_ruffles;

        context c = () =>
        {
            an_item_for_a_bag_of_ruffles = an<IShoppingCartItem>();
            a_bag_of_ruffles = an<IProduct>();

            when_the(shopping_cart_item_factory).is_told_to(x => x.create_a_shopping_cart_item_from(a_bag_of_ruffles))
                .Return(an_item_for_a_bag_of_ruffles);
        };

        because b = () => sut.add(a_bag_of_ruffles);

        [Observation]
        public void an_item_for_the_bag_of_ruffles_should_be_stored_in_the_cart()
        {
            shopping_cart_items.should_contain(an_item_for_a_bag_of_ruffles);
        }

        [Observation]
        public void should_have_items_for_both_the_can_of_pepsi_and_the_bag_of_ruffles()
        {
            shopping_cart_items.should_contain(an_item_for_a_can_of_pepsi, an_item_for_a_bag_of_ruffles);
        }
    }

The use of the lambdas for the context (setup) and because(action of the system under test) causes them to not jump to the eyes as quickly as the concern and the observations (as they attributes help draw your eyes to them faster. Lots of tests were written in class. The context block can be shared with other contexts that occur up the hierarchy. Outside of the mechanics of how setup and teardown are now handled, it is still very much a NUnit/MbUnit flavoured test with a heavy BDD spin on it. One of the nice things that I have started taking advantage of is having the system under test automatically created for me (in a base class, with the option to override). I have also put in a lot of effort to shield myself from the noise of mock object frameworks and testing specific nomenclature (notice the an method).

I am going to be releasing some more stuff on this in the next couple of days. I just wanted to give a sneak peek. You will notice that I have opted to not bother trying to come up with meaningful names for the context and because fields. I name the fixture/concern to be descriptive as to the context of the sut I am testing, and the names of the observations fill out the rest of the meaty details.

Thoughts?

Develop With Passion!!

In response to a comment from the  last post, here is the interface of the BDDExtensions that were driven out from the last NBDN course:

    public static class BDDExtensions
    {
        public static void force_traversal<T>(this IEnumerable<T> items)
        public static void should_be_null(this object item)
        public static void should_contain<T>(this IEnumerable<T> items, T item)
        public static void should_be_greater_than<T>(this T item, T other) where T : IComparable<T>
        public static void should_not_be_equal_to<T>(this T item, T other)
        public static void should_be_equal_ignoring_case(this string item, string other)
        public static void should_only_contain<T>(this IEnumerable<T> items, params T[] items_to_find)
        public static void should_only_contain_in_order<T>(this IEnumerable<T> items, params T[] items_to_find)
        public static void should_be_true(this bool item)
        public static void should_be_false(this bool item)
        public static void should_be_equal_to<T>(this T actual, T expected)
        public static ExceptionType should_throw_an<ExceptionType>(this Action work_to_perform)
        public static void should_not_throw_any_exceptions(this Action work_to_perform)
        public static void should_be_an_instance_of<Type>(this object item)
        public static void should_not_be_null(this object item}
    }

This is the main base set of extensions. I usually have a whole family of application specific extensions that come into play for doing application specific assertions.

Develop with Passion!!

Thanks to a suggestion from Albert Weinert I have added 2 new test attributes to the spec helpers layer of my codebase (this is the folder that contains all of the test related utilities).

For a long time I have been aliasing the TestAttribute and changing it to observation. Instead with a suggestion from Albert, I have now added 2 new attribute classes to the spec helpers layer (Albert sent me the code, I just renamed the TestPatternAttribute class):

    [AttributeUsage(AttributeTargets.Method,AllowMultiple = false)]
    public class ObservationAttribute : TestPatternAttribute
    {}

    [AttributeUsage(AttributeTargets.Class,AllowMultiple = false)]
    public class Observations : TestFixturePatternAttribute
    {
        public Observations(string description) : base(description)
        {
        }

        public Observations()
        {
        }

        public override IRun GetRun()
        {
            var run = new SequenceRun();
            run.Runs.Add(new OptionalMethodRun(typeof(SetUpAttribute),false));
            run.Runs.Add(new MethodRun(typeof(ObservationAttribute),true,true));
            run.Runs.Add(new OptionalMethodRun(typeof(TearDownAttribute),false));
            return run;
        }
    }

This is much cleaner than aliasing (as well as adhering to DRY). I chose to keep this in my codebase vs rolling it into MbUnit as it gives people the freedom to name the attributes the way they feel. Because all of my test fixtures inherit from a base fixture, this change only required changing the attribute on my base test fixture as well as a quick search/replace to eliminate the:

using Observation = MbUnit.Framework.TestAttribute;

Thanks Albert.

Develop With Passion

In my ongoing quest to simplify the use of mock objects and to make the test code that I write remove the need for testing specific nomenclature. I made a small update to the BDDExtensions that I use when working with Rhino Mocks. Here is the class in question:

    public static class RhinoMocksExtensions
    {
        public static VoidMethodCallOccurance<T> was_told_to<T>(this 
T mock, Action<T> item)
        {
            return new VoidMethodCallOccurance<T>(mock, item);
        }

        public static IMethodOptions<R> when_told_to<T, R>(this T mock
, Function<T, R> func) where T : class
        {
            return mock.Stub(func);
        }
    }

The above 2 extension methods are the only ones I need to use when working with my mock objects. As you can see, they are just non-testing-nomenclature specific wrappers around existing rhino mocks methods.The was_told_to extension method is a method that I use to verify that a void method call message was sent to a mock object. You can see that the method returns a VoidMethodCallOccurance class that looks like this:

    public class VoidMethodCallOccurance<T>
    {
        public Action<T> action;
        private T mock;

        public VoidMethodCallOccurance(T mock, Action<T> action)
        {
            this.mock = mock;
            this.action = action;
            mock.AssertWasCalled(action);
        }

        public void times(int number_of_times_the_method_
should_have_been_called)
        {
            mock.AssertWasCalled(action, y => y.Repeat.Times(number_of
_times_the_method_should_have_been_called));
        }

        public void only_once()
        {
            times(1);
        }

        public void twice()
        {
            times(2);
        }   
    }

This class allows you to specify the number of times a method was called on mock object. Which allows you to do this:

        [Observation]
        public void should_tell_the_log_4_net_initialization_command_
to_run()
        {
            initialization_command.was_told_to(x => x.run())
.only_once();
        }

as opposed to this:

        [Observation]
        public void should_tell_the_log_4_net_initialization_command_
to_run()
        {
            initialization_command.AssertWasCalled(x => x.run()
,y => y.Repeat.Times(1));
        }
 
It is a small change, but one that, IMHO, adds a lot to the
readability of the test.
 
Develop With Passion!!

I am currently going through my existing application and refactoring for a bit more readability (with a focus on natural language). Could I get your feedback onthe readability of the following piece of code which demonstrates a chain of responsibility:

Run.the<wire_up_global_error_handling>()
   .then<initialize_the_container_for_the_user_interface>()
   .then<initialize_the_user_interface_registry>()
   .then<initialize_the_ui_images_registry>()
   .then<initialize_the_main_menus>()
   .execute();

Underscores in code seem to have permeated a lot of my thinking. And I am currenlty playing around with lowercase method naming with underscores to separate significant words. How would you feel if you were presented with this code to read? Be brutally honest!!

Develop With Passion!!

Having downloaded and started to use Rhino Mocks 3.5 beta pretty much as soon as Oren released. I am very happy with the AAA style (Arrange, Act, Assert) and the readability and brevity it has brought to my tests. The current project I am on has a huge set of tests. Here is an example of using Rhino Mocks, in conjunction with some BDD style naming:

    [Concern(typeof (UnitOfWorkFactory))]
    public class When_a_new_unit_of_work_is_requested_to_be_created : behaves_like_unit_of_work_with_scope_storage_in_play
    {
        protected override void because()
        {
            sut.Create();
        } 

        [Observation]
        public void Should_access_scoped_storage_to_determine_if_a_unit_of_work_is_already_active()
        {
            scoped_storage.was_told_to(item => item.DoesNotContain<IUnitOfWork>());
        }
    }

    [Concern(typeof (UnitOfWorkFactory))]
    public class When_creating_a_unit_of_work_and_the_scoped_storage_does_not_contain_an_active_unit_of_work : behaves_like_unit_of_work_with_scope_storage_in_play
    {
        private ISession session;

        protected override void establish_context()
        {
            base.establish_context();
            session = Dependency<ISession>();
            scoped_storage.setup_result(item => item.DoesNotContain<IUnitOfWork>()).Return(true);
            nhibernate_session_factory.setup_result(item => item.OpenSession()).Return(session);
        }

        protected override void because()
        {
            sut.Create();
        }

        [Observation]
        public void Should_store_the_newly_created_unit_of_work_in_scoped_storage()
        {
            scoped_storage.was_told_to(item => item.Store(Arg<IUnitOfWork>.Matches(uow => uow != null)));
        }
    }

    [Concern(typeof (UnitOfWorkFactory))]
    public class When_a_new_unit_of_work_is_requested_and_one_already_exists_in_scoped_storage : behaves_like_unit_of_work_with_scope_storage_in_play
    {
        private ISession session;
        private IUnitOfWork new_unit_of_work;
        private IUnitOfWork active_unit_of_work;

        protected override void establish_context()
        {
            base.establish_context();
            session = Dependency<ISession>();
            active_unit_of_work = Dependency<IUnitOfWork>();
            nhibernate_session_factory.setup_result(item => item.OpenSession()).Return(session);
            scoped_storage.setup_result(item => item.Contains<IUnitOfWork>()).Return(true);
            scoped_storage.setup_result(item => item.Retrieve<IUnitOfWork>()).Return(active_unit_of_work);
        }

        protected override void because()
        {
            new_unit_of_work = sut.Create();
        }

        [Observation]
        public void Should_return_a_non_disposing_unit_of_work_proxy()
        {
            new_unit_of_work.should_be_an_instance_of<NonDisposableUnitOfWork>();
        }
    }
 

I am no longer using the automocking container so you are probably wondering what the Dependency method call is all about. It is simply a method defined on a base ContextSpecification class whose definition is as follows:

    [Context]
    public abstract class ContextSpecification
    {
        [SetUp]
        public void setup()
        {
            unit_test_container.Initialize();
            establish_context();
            because();
        }

        [TearDown]
        public void teardown()
        {
            after_each_specification();
            unit_test_container.tear_down_and_unregister_from_dependency_registry();
        }

        protected abstract void because();
        protected abstract void establish_context();

        protected virtual void after_each_specification()
        {
        }

        protected InterfaceType Dependency<InterfaceType>()
        {
            return MockRepository.GenerateMock<InterfaceType>();
        }

        protected InterfaceType Stub<InterfaceType>()
        {
            return MockRepository.GenerateStub<InterfaceType>();
        }
    }

And I have some extension methods that wrap the RhinoMocks "assertions" with more language oriented assertions: Instead of AssertWasCalled you get was_told_to, and so on.

Develop With Passion!!

For the longest time (the last 4 months!!) I have been using the following style of code to determine whether exceptions are thrown in my codebases:

typeof (InterfaceResolutionException).ShouldBeThrownBy(() => DependencyRegistry.GetMeAn<IDbConnection>());

As you can see, all that I am doing here is leveraging an extension method that hangs of the type class:

        public static void ShouldBeThrownBy(this Type exceptionType,Action workToDo)
        {
            GetExceptionFromPerforming(workToDo).ShouldBeAnInstanceOf(exceptionType);            
        }

This extension method lives in a library of extension methods that I use when doing Behavior Driven Development and trying to leverage natural language as close as possible vs the traditional Assert this/that.

I just switched it up a bit to change it to make it completely foolproof, as with the original extension method you could have easily done this:

typeof (SqlConnection).ShouldBeThrownBy(() => DependencyRegistry.GetMeAn<IDbConnection>());

This code would compile and run, but SqlConnection is not an exception type. What I want to be able to do, to address this issue is flip things around like this: 

(() => DependencyRegistry.GetMeAn<IDbConnection>()).ShouldThrowA<InterfaceResolutionException>();

Notice how I am trying to use 2 different concepts here:

• Extension methods having off of a lambda expression
• Generics to ensure that the type provided to the ShouldThrowA method is an derivative of Exception

The only real problem with this is that you can't have an extension method that hangs off a lambda. What I can do is the following to get started:

        public static void ShouldThrowA<ExceptionType>(this Action workToDo) where ExceptionType : Exception
        {
            GetExceptionFromPerforming(workToDo).ShouldBeAnInstanceOf<ExceptionType>();
        }

        public static Exception GetExceptionFromPerforming(Action work)
        {
            try
            {
                work();
            }
            catch(Exception e)
            {
                return e;
            }
            return null;
        }

The first thing that I did is to create an extension method that belongs to any Action delegate instance. Notice the use of the generic constraint to ensure that the generic type parameter provided to the method is an actual derivative of Exception, which ensures that using this method is only applicable to exception throwing behaviors for a specific exception type. The second method GetExceptionFromPerforming (you will notice that I commonly use a style of naming that makes the method name coupled with its parameters the full name of the method, read the line as GetExceptionFromPerforming(work) vs GetExceptionFromPerformingWork(work), just a little bit of redundancy I don't care for) returns the exception caught while trying to execute the Action.

The ShouldBeAnInstanceOf method is another extension method that gets associated with any object, it just makes use of an existing assertion in the MbUnit library.

All of the building blocks are in place there is only one problem. I can't do this:

(() => DependencyRegistry.GetMeAn<IDbConnection>())
                    .ShouldThrowA<InterfaceResolutionException>();

So with just the following new class added to the my BDD Extensions Class:

public static class The
{
  public static Action Action(Action workToDo)
  {
    return workToDo;
  }
}

Looks a little weird, to have a method that looks like all it is doing is returning what it was called with, but in this case it is actually allowing us to allow assignment of the lambda to a known type which ultimately allows us to have extension methods that are bound to that known type (in this case the Action delegate). With all of these places in place this is how I now do assertions for exceptions thrown in a piece of SUT code:

The.Action(() => DependencyRegistry.GetMeAn<IDbConnection>())
                    .ShouldThrowA<InterfaceResolutionException>(); 

In this code the SUT is the DependencyRegistry which is actually a Static Gateway to container functionality.

Develop With Passion!!

Looks like Ilya Ryzhenkov of JetBrains shares my same thoughts with regards to using implicitly typed local variables!!

It is an interesting read that you may want to check out here.

Develop With Passion!!

I had a couple of interesting discussions at the recent MVP summit around my preference to using the var keyword in my recent set of codebases.

I argued that people who are already in the habit of expressively naming their variables are going to be much more open to dropping the extra "noise" of specifying the type on both sides of the variable declaration.

Having been exposed to dynamic languages (Ruby) has definitely altered my perspective with regards to considering this:

IList<Customer> listOfCustomers = new List<Customer>()

Much more noisy than this:

var listOfCustomers = new List<Customer>()

As I strive toward more readable, intent revealing code, I find myself looking at the intent behind the usage of the variable coupled with a meaningful name, vs the actual type. In reality, I find the the argument to not use var is a moot point in a static environment that provides you with all the information you need once you hit the "."

How do you var?

Develop With Passion!!

This is just a message to those people who are interested in attending next months Nothin But .Net session in Austin, TX. There are only 6 spots left. Tell your friends, tell your co-workers. This session promises to be an absolute blast. The attendance roster is varied and will provide for lots of interesting conversation and pair programming opportunities.

You can register for the course here:

http://www.acteva.com/booking.cfm?bevaID=150826

Develop With Passion!!

Last week I had the honor of presenting at the Calgary .Net User group on the topic of Generics in .Net. In retrospect, I think the fact that I was leveraging vs2008, and C# 3.5 potentially clouded focus on raw generics.

Nonetheless, there was lots of good discussion, and a lot of concepts were able to get demonstrated. Among the nuggets that were started:

• Generic Ranges
• Specification based querying
• Strongly typed dto mappers
• Generic dto mappers
• Type safe query objects

All code was created on the fly during the presentation, and 3 blesses attendees were able to walk away with a copy of ReSharper.

As a side note, my speaking schedule is starting to fill up for the year, if you think your user group would be interested in having me out to do a presentation; please do not hesitate to contact me at: jp@jpboodhoo.com.

The code for the presentation is available here. None of the 3rd party libraries are present in the download, if you actually want to run the code you will have to go and download the tools specified in the following folders:

• build\tools
• thirdparty\tools

To extract the rar file you can use WinRar or 7Zip (I am sure there are lots of others).

Develop With Passion!!

Ever since the nightly builds for ReSharper 4.0 went live, being the REA (Resharper early adopter) that I am, I downloaded it and have been using it on my C# 3.5 projects. I am happy to report that even though it is in the pre EAP phase, it is extremely solid and a joy to work with.

The support for the new language features such as extension methods, automatic properties ... is great. So far I have had only one exception dialog pop up. For those of you who have braved prior EAP's for ReSharper (remember ReSharper 2.0 EAP!!!) you have probably already developed a thick skin for the exception dialogs that typically pop up during EAP. So far this is not the case.

In all honesty, those of us who love ReSharper would be more than willing to put up with multiple exception dialogs as, let's face it, studio without ReSharper == "I won't use it".

So what are you waiting for, head over and download the latest nightly build. Keep in mind that results may vary between use as well as different nightly builds!!

Develop with Passion!!

The following snippet of code (C# 3.5) is allowable, and gives you the benefit of unnecessary extra verbosity with the benefits of encapsulation. Of course, if you need to implement logic in your property, then you don't want to think about automatic properties:

public T Item { get; private set; }

Had a question recently with regards to presenter first development in a smart client application.

“How do you tell the presenter to run?”

In presenter first style, the presenter will be the first point of contact from the ApplicationController. It will be the presenters responsibility to tell its associated view to render, etc. In my current smart client application I am making heavy use of commands that can be attached to arbitrary elements : buttons, linkbutton, menu items, to initiate the running of a command. Here is a small piece of code that should give away how I am hooking up commands to presenters in the application:

    public class RunPresenterCommand<Presenter> : ICommand where Presenter : IPresenter
    {
        private IApplicationController controller;

        public RunPresenterCommand(IApplicationController controller)
        {
            this.controller = controller;
        }

        public void Execute()
        {
            controller.Run<Presenter>();
        }
    }

Notice that all this command does when told to execute is to dispatch a call to the application controller, telling it to run the associated presenter. This keeps the responsibility of starting up the presenter in the place that it should be, the ApplicationController.

Hope that answers the question.

This is a very short post to demonstrate the concept that I mentioned in parting during the last post.

“And of course I could eliminate the method call tracker altogether if I made use of lambda expressions and parsed the expression tree to see what method was called”

Someone fired an email asking how to do this so I thought I would quickly implement to show them the result. You can now also set filters on the interceptor by use of a lambda expression. So instead of this (and you can still do this):

IInterceptorConstraint<IAnInterface>constraint = sut.AddInterceptor<SomeInterceptor>();
constraint.InterceptOn.OneMethod();

or this: 

IInterceptorConstraint<IAnInterface> constraint = sut.AddInterceptor<SomeInterceptor>();
constraint.InterceptOnMethods(constraint.InterceptOn.ValueReturningMethodWithAnArgument(1));

You can now use a lambda expression which negates the need to store a reference to the constraint to apply constraints:

sut.AddInterceptor<SomeInterceptor>()
   .InterceptCallTo(x => x.OneMethod())
   .InterceptCallTo(x => x.SecondMethod());

The InterceptCallTo method accepts an ExpressionTree of type Action<T> where T is the target to be proxied. The code to parse this expression tree into a method call is very simple. The InterceptorConstraint class just forwards the call onto its MethodCallTracker:

public IInterceptorConstraint<Target> InterceptCallTo(Expression<Action<Target>> expression)
{
    callTracker.AddCallInferredFrom(expression);
    return this;
}

Notice that the method returns the InterceptorConstraint itself, which is what allows for the very limited fluent interface. As far as parsing the expression to store the method to be intercepted on, it is all done by the MethodCallTracker itself: 

public void AddCallInferredFrom(Expression<Action<T>> expression)
{
    MethodCallExpression methodCallExpression = expression.Body as MethodCallExpression;
    if (methodCallExpression != null) AddCallFor(methodCallExpression.Method.Name);
}

That’s it, that’s all. The AddCallFor method is now called from both here and the original Interception tracker to store the list of methods that should be intercepted on.

Develop with Passion!!

Another awesome course is entering the lineup for the March timeframe also. Unlike Wendy’s kick butt WPF course which is occuring in New York in the month of March, this course will be a Canuck affair, to be held in the winter wonderland of Edmonton!!

Donald Belcham (aka. Igloo Coder) will be the instructor for the course, and he has a crazy week lined up for the people interested in stepping up for the challenge.

You can register for the course here. Sign up quick, as seating is limited. Here is a description of the course:

Overview

Nothin’ But C# v3.5 is a 5 day boot camp styled course that provides in depth training in the new language features in version 3.5 of the .Net Framework.  Attendees will work with the new features in this version of the Framework to gain an understanding of their operation at a very deep level and aid them in the pragmatic implementation of these tools in their daily development.

While learning to use the new features of .Net v3.5, the students will also be introduced to foundational object oriented programming techniques.  They will learn both how to implement these techniques as well as understanding the benefits that they offer.

By the end of the course you will have knowledge of the new features at a very detailed level.  You will understand the concepts behind their existence, the limitations that they have and how you can use them to write better code in real applications.  None of the concepts will be taught using wizards, drag and drop or templates.  Attendees will be learning how to implement these language features combined with OO best practices and using techniques such as TDD.

Attendees should have a good understanding of programming in .Net and OO practices.  This is not an introductory course for learning to program with .Net.

Core Concepts Overview

• New language features in .Net 3.5
• Extension Methods – helping to make fluent interfaces
•  Lambda Expressions – from refreshers on delegates all the way to the lean lambda
•  Linq – for SQL, XML, Objects, etc.
• New User Interface Controls
•  ASP.NET MVC
• Object Oriented Foundations

Detailed Topic Coverage Breakdown

·          New Language Features

o    Simple Properties

o    Anonymous Constructors

o    Anonymous Types

o    DateTime2

o    TimeZoneInfo

o    HashSet<T>

o    Active Directory Integration

o    Diagnostics

o    Cross Framework compatibility

·          Extension Methods

o    Using with primitive types

o    Using with complex types

o    Using with enumerations

o    Using to build fluent interfaces

o    How they are interpreted by the compiler

o    Dangers and code smells

·          Lambda Expressions

o    Refresher on Delegates

o    Refresher on Anonymous Delegates

o    Refresher on Predicates

o    Learn the syntax

o    Replacing Anonymous Delegates with Lambdas

o    How are they interpreted by the compiler

·          Linq

o    Linq fundamentals

o    How is Linq interpreted by the compiler

o    Linq to SQL

o    Linq to XML

o    Linq to Objects

o    Linq to Dataset

o    Linq and performance

·          UI Components

o    ListView control

o    DataPager control

·          ASP.NET MVC

o    MVC fundamentals

o    Writing Views

o    Routing

o    Plugging in Inversion of Control containers

o    Testability

·          Object Oriented Foundations

o    Single Responsibility Principle

o    Separation of Concerns

o    Design by Contract

o    Dependency Injection and Inversion of Control

o    Design Patterns

Target Audience

This is an intermediate level course that will prepare developers to work with the release of the .Net 3.5 framework.  Attendees should have a working knowledge of .Net and knowledge of the following

•         Core working knowledge of either Visual Basic or C#
•         Base grasp of Object Oriented Design principles
•         High level understanding of SQL Server and XML

Intended Outcomes

Once attendees have completed this course they should have a strong, practical understanding of the following:

• New base language features in the .Net 3.5 framework
• Lambda expressions
• Linq for SQL, XML and Objects
• Extension methods
• ASP.NET MVC
• Design by contract
• Practical application of basic patterns
• Test Driven Development

Donald Belcham is a software developer with a strong focus on .NET development platforms.  He has been building application with .NET since the release of version 1.1 of the framework.  More recently Donald has become very active in the developer community as the President of the Edmonton .NET User Group.  The combination of that role and a passion for bettering the skills of any software developer, Donald has become a regular speaker at User Groups, Code Camps and conferences across North America.  He advocates and speaks on the creation of a solid set of foundational object oriented skills and understandings that can then be used with any of the many appropriate tools.  These activities and beliefs have garnered Donald a Microsoft MVP award in C#.

Donald can be reached at donald.belcham@igloocoder.com and via phone at 780.974.5860.  He welcomes open and frank conversations on different development techniques at his website www.igloocoder.com

Once again, you can register for the course here. If you have any questions do not hesitate to contact me at jp@jpboodhoo.com

Had the question the other day:

“How could I dynamically create a proxy around an object (interface based proxies are not a problem) and then selectively apply interceptors at a method by method level if necessary”.

Let’s clear up a bit of terminology so that everyone is on the same page with regards to the problem at hand:

Proxy – An object that implements the same interface as a target object and intercepts methods calls to the target to perform some sort of pre and or post method invocation.

Interceptor – An object that can be plugged into a proxy to perform a pre/post method invocation step. Common example that most people are familiar with is a LoggingInterceptor.

Attacking the problem test first drove me down a fairly interesting path that I was pleased with for a first cut. I’ll explain the details in a minute, but examples speak a lot louder than words. I created a couple of dummy interfaces and a simple object to demonstrate the proxying/interception capabilities. It should also be noted that I am making use of Castle DynamicProxy as I feel it is an much easier barrier of entry for people who want to take advantage of creating dynamic proxies vs dropping down to the wire and leveraging Reflection.Emit classes directly (though that is something that I strongly recommend playing with a couple of times, just so you have an understanding for it). Here are the interceptors that will be used in this example:

    public class SomeInterceptor : IInterceptor
    {
        public void Intercept(IInvocation invocation)
        {
            Console.Out.WriteLine("Interception occured on method {0} with {1}",invocation.Method.Name,this.GetType().Name);
            invocation.Proceed();
        }
    }

    public class SomeOtherInterceptor : IInterceptor
    {
        public void Intercept(IInvocation invocation)
        {
            Console.Out.WriteLine("Interception occured on method {0} with {1}",invocation.Method.Name,this.GetType().Name);
            invocation.Proceed();
        }
    }

As you can see. Both of these interceptors are ridiculously simple. They both implement the IInterceptor interface that comes from Castle.Core, the interface itself only has one method called Intercept which is the method that will get invoked by the proxy when a method call is intercepted. Both of these classes lived in a test fixture class file, so I was not concerned with the evident duplication. Here are the interface and implementation for the item that is going to be proxies:

    public interface IAnInterface
    {
        void OneMethod();
        void SecondMethod();
        int FirstValueReturningMethod();
        int ValueReturningMethodWithAnArgument(int number);
    }

    public class SomeImplementation : IAnInterface
    {
        public void OneMethod()
        {
            Console.Out.WriteLine("Real work is being done in OneMethod");       
        }

        public void SecondMethod()
        {
            Console.Out.WriteLine("Real work is being done in SecondMethod");
        }

        public int FirstValueReturningMethod()
        {
            Console.Out.WriteLine("Real work is being done in FirstValueReturningMethod");
            return 1;
        }

        public int ValueReturningMethodWithAnArgument(int number)
        {
            Console.Out.WriteLine("Real work is being done in ValueReturningMethodWithAnArgument");
            return 1 + number;
        }
    }

Again, substitute this interface and implementation with any interface/implementation pair that you would want to create a proxy for in your own application. With all of those, I’ll show you some usages of the final product before explaining the solution:

Scenario 1 : Intercept on all method invocations with a SomeInterceptor

        [Test]
        public void Should_proxy_all_methods_with_some_interceptor()
        {            
            IAnInterface anImplementationOfTheInterfaceToProxy = new SomeImplementation();

            sut = new ProxyBuilder<IAnInterface>();
            sut.AddInterceptor<SomeInterceptor>();

            IAnInterface proxy = sut.CreateProxyFor(anImplementationOfTheInterfaceToProxy);
            proxy.OneMethod();
            proxy.SecondMethod();
        }

Which results in the following console output:

Interception occured on method OneMethod with SomeInterceptor
Real work is being done in OneMethod
Interception occured on method SecondMethod with SomeInterceptor
Real work is being done in SecondMethod

Notice that the interceptor was leveraged on both method calls prior to the call on the underlying item being made.

Scenario 2 : Intercept on all method invocations with multiple interceptors

        [Test]
        public void Should_proxy_all_methods_with_multiple_interceptors()
        {
            IAnInterface anImplementationOfTheInterfaceToProxy = new SomeImplementation();

            sut = new ProxyBuilder<IAnInterface>();
            sut.AddInterceptor<SomeInterceptor>();
            sut.AddInterceptor<SomeOtherInterceptor>();

            IAnInterface proxy = sut.CreateProxyFor(anImplementationOfTheInterfaceToProxy);
            proxy.OneMethod();
            proxy.SecondMethod();
            
        }

Which produces the following console output:

Interception occured on method OneMethod with SomeInterceptor
Interception occured on method OneMethod with SomeOtherInterceptor
Real work is being done in OneMethod
Interception occured on method SecondMethod with SomeInterceptor
Interception occured on method SecondMethod with SomeOtherInterceptor
Real work is being done in SecondMethod 

In this scenario both of the individual interceptors were invoked on any method call to the proxied item. Ok, so that was easy, lets try the next one:

Scenario 3 : Intercept on specific method invocations with a Single interceptor:

        [Test]
        public void Should_proxy_only_targeted_methods_with_a_single_interceptor()
        {
            sut = new ProxyBuilder<IAnInterface>();
            anImplementation = new SomeImplementation();

            IInterceptorConstraint<IAnInterface> constraint = sut.AddInterceptor<SomeInterceptor>();
            constraint.InterceptOn.OneMethod();

            IAnInterface proxy = sut.CreateProxyFor(anImplementation);
            proxy.OneMethod();
            proxy.SecondMethod();
        }

Which produces the following output:

Interception occured on method OneMethod with SomeInterceptor
Real work is being done in OneMethod
Real work is being done in SecondMethod 

Notice in the test above the use of the constraint that is returned from the Add method. Notice the call to the constraint.InterceptOn.OneMethod(). That is actually setting a filter to only enable the interceptor when that method is invoked on the proxy. For those familiar with Natural Mocks syntax (Rhino Mocks / TypeMock) this should look similar. It also has the nice benefit of not requiring the use of strings to specify which methods to filter on. Which means that it is also refactoring friendly. Notice that even though 2 method calls are made on the proxy, the interceptor only kicks in for the method that the constraint was configured for!!

Scenario 4 : Intercept on specific method invocations with differing interceptors:

        [Test]
        public void Should_proxy_only_targeted_methods_with_differing_interceptors()
        {
            sut = new ProxyBuilder<IAnInterface>();
            anImplementation = new SomeImplementation();

            IInterceptorConstraint<IAnInterface> constraint1 = sut.AddInterceptor<SomeInterceptor>();
            constraint1.InterceptOn.OneMethod();

            IInterceptorConstraint<IAnInterface> constraint2 = sut.AddInterceptor<SomeOtherInterceptor>();
            constraint2.InterceptOn.SecondMethod();

            IAnInterface proxy = sut.CreateProxyFor(anImplementation);
            proxy.OneMethod();
            proxy.SecondMethod();
        }

Which results in the following console output:

Interception occured on method OneMethod with SomeInterceptor
Real work is being done in OneMethod
Interception occured on method SecondMethod with SomeOtherInterceptor
Real work is being done in SecondMethod 

Notice how in this example the interceptors are firing selectively for the methods that they were configured for.

Finally you can configure multiple method constraints at a time using the following syntax:

            constraint.InterceptOnMethods(
                constraint.InterceptOn.FirstValueReturningMethod(),
                constraint.InterceptOn.ValueReturningMethodWithAnArgument(0));

Again, the syntax for this was heavily inspired by prolonged usage of Rhino Mocks. So let’s inspect the players that come together to make this all work:

    public class ProxyBuilder<T> : IProxyBuilder<T>
    {
        private IProxyFactory proxyFactory;
        private IInterceptorConstraintSet constraintSet;


        public ProxyBuilder():this(new ProxyFactory(),new InterceptorConstraintSet())
        {
        }

        public ProxyBuilder(IProxyFactory proxyFactory, IInterceptorConstraintSet constraintSet)
        {
            this.proxyFactory = proxyFactory;
            this.constraintSet = constraintSet;            
        }

        public IInterceptorConstraint<T> AddInterceptor<Interceptor>() where Interceptor : IInterceptor,new()
        {
            constraintSet.AddConstraintFor<Interceptor,T>();
            return constraintSet.GetConstraintFor<Interceptor,T>();
        }


        public T CreateProxyFor<T>(T instance)
        {
            return proxyFactory.CreateProxyUsing<T>(instance, constraintSet);
        }
    }

This is entry point to the api used to create proxies and associate interceptors with them. Driving out the design in a test first manner really helped me push off responsibilities to the last possible moment. Which leaves the ProxyBuilder class fairly simple. It leverages both a ProxyFactory and an InterceptorContraintSet. The InterceptorConstraintSet is just a strongly typed collection of constraints with a little bit of smarts to it:

    public class InterceptorConstraintSet : IInterceptorConstraintSet
    {
        private IDictionary<Type, object> constraints;
        private IInterceptorConstraintFactory constraintFactory;


        public InterceptorConstraintSet():this(new Dictionary<Type,object>(),new InterceptorConstraintFactory(new ProxyFactory()))
        {
            
        }

        public InterceptorConstraintSet(IDictionary<Type, object> constraints, IInterceptorConstraintFactory constraintFactory)
        {
            this.constraints = constraints;
            this.constraintFactory = constraintFactory;
        }

        public void AddConstraintFor<Interceptor, Target>() where Interceptor : IInterceptor, new()
        {
            if (constraints.ContainsKey(typeof(Interceptor))) return;

            constraints.Add(typeof (Interceptor), constraintFactory.CreateFor<Interceptor, Target>());
        }

        public IInterceptorConstraint<Target> GetConstraintFor<Interceptor, Target>() where Interceptor : IInterceptor, new()
        {
            return (IInterceptorConstraint<Target>) constraints[typeof (Interceptor)];
        }


        public IInterceptor[] AllInterceptors<Target>()
        {
            return SetOfAllInterceptorsFor<Target>().AsList().ToArray();
        }


        private IEnumerable<IInterceptor> SetOfAllInterceptorsFor<Target>()
        {
            foreach (IInterceptorConstraint<Target> constraint in constraints.Values)
            {
                yield return constraint.BuildInterceptor();
            }
        }

    }

The SetOfAllInterceptorsFor<Target> method is interesting as this is where the work to create the interceptors for a proxy is delegated to the constraint. The InterceptorConstraint and its accompanying collaborators is what allows for the natural syntax:

    public class InterceptorConstraint<Target,Interceptor> : IInterceptorConstraint<Target> where Interceptor : IInterceptor,new()
    {
        private readonly IMethodCallTracker<Target> callTracker;


        public InterceptorConstraint(IMethodCallTracker<Target> callTracker)
        {
            this.callTracker = callTracker;
        }


        public Target InterceptOn
        {
            get { return callTracker.Target; }
        }

        public void InterceptOnMethods(params object[] makeMethodCallsUsingInterceptOnProperty)
        {

        }


        public void InterceptOnMethods(params Action[] makeMethodCallsToInterceptOnPropertyInsideOfActionDelegate)
        {
            foreach (Action action in makeMethodCallsToInterceptOnPropertyInsideOfActionDelegate)
            {
                action();
            }
        }

        public IInterceptor BuildInterceptor()
        {
            if (callTracker.CallsWereMade) return new SelectiveInterceptor(new Interceptor(), callTracker.AllMethods());

            return new Interceptor();
        }
    }

The work of doing the interceptor filtering is done in the BuildInterceptor method. The InterceptorConstraint makes use of a MethodCallTracker which keeps track of whether calls were made to filter on selective methods. If the client is requesting a filtered interceptor the InterceptorConstraint returns an instance of a SelectiveInterceptor. SelectiveInterceptor is a proxy for an Interceptor (I know that is a mouthful!!):

    public class SelectiveInterceptor : IInterceptor
    {
        private IInterceptor interceptor;
        private IDictionary<string,string> methodsToInterceptOn;


        public SelectiveInterceptor(IInterceptor interceptor, IDictionary<string, string> methodsToInterceptOn)
        {
            this.interceptor = interceptor;
            this.methodsToInterceptOn = methodsToInterceptOn;
        }


        public void Intercept(IInvocation invocation)
        {
            if (methodsToInterceptOn.ContainsKey(invocation.Method.Name))
            {
                interceptor.Intercept(invocation);
                return;
            }
            invocation.Proceed();                        
        }
    }

Selective interceptor decides whether or not to forward the call onto the associated interceptor, if the method is not in the dictionary of methods to intercept on, it bypasses the interceptor and directly forwards the call onto the item to proxy.

Notice the user of : new Interceptor();

This creates a new instance of whatever the interceptor type was that was specified by the AddInterceptor<Interceptor> method call back on ProxyBuilder. This works because of the generic constraint that ensured that the IInterceptor implementation also had a public no-arg constructor.

Last but not least, you are probably curious as to how the natural syntax is enabled? Take a look at the MethodCallTrackerFactory class:

    public class MethodCallTrackerFactory : IMethodCallTrackerFactory
    {
        private ProxyGenerator proxyGenerator;

        public MethodCallTrackerFactory(ProxyGenerator proxyGenerator)
        {
            this.proxyGenerator = proxyGenerator;
        }

        public IMethodCallTracker<T> CreateFor<T>()
        {
            MethodCallTracker<T> methodCallTracker = new MethodCallTracker<T>();
            T target = proxyGenerator.CreateInterfaceProxyWithoutTarget<T>(methodCallTracker);
            methodCallTracker.Target = target;
            return methodCallTracker;
        }
    }

The ProxyGenerator class is supplied by Castle.DynamicProxy. I am using it to create a proxy around an interface without an actual underlying target:

T target = proxyGenerator.CreateInterfaceProxyWithoutTarget<T>(methodCallTracker);

Notice how after the MethodCallTracker is instantiated, it is passed in as an argument to the CreateInterfaceProxyWithoutTarget method? This method takes either a single or variable array of IInterceptor implementations. That’s right. The MethodCallTracker is itself as IInterceptor implementation. It intercepts calls on its Target property so that it can store the calls to be used in the Interception filtering process:

    public class MethodCallTracker<T> : IMethodCallTracker<T>
    {
        public T Target{get;set;}

        private IDictionary<string, string> methodNames;


        public MethodCallTracker() : this(new Dictionary<string, string>())
        {
        }

        public MethodCallTracker(IDictionary<string, string> methodNames)
        {
            this.methodNames = methodNames;
        }


        public void Intercept(IInvocation invocation)
        {
            SetReturnValueFor(invocation);

            if (methodNames.ContainsKey(invocation.Method.Name)) return;

            methodNames.Add(invocation.Method.Name, invocation.Method.Name);
        }

        private void SetReturnValueFor(IInvocation invocation)
        {
            Type returnType = invocation.Method.ReturnType;
            
            if (returnType == typeof(void)) return;
            
            invocation.ReturnValue = (returnType.IsValueType ? Activator.CreateInstance(returnType) : null);
        }


        public bool CallsWereMade
        {
            get { return methodNames.Count > 0; }
        }


        public IDictionary<string, string> AllMethods()
        {
            return methodNames.Copy();
        }
    }

And finally, the glue that ties it all together. ProxyFactory, this class actually creates proxies instances leveraging the Castle ProxyGenerator as well as the completed InterceptorConstraintSet:

    public class ProxyFactory : IProxyFactory
    {
        private ProxyGenerator proxyGenerator;
        private IMethodCallTrackerFactory methodCallTrackerFactory;


        public ProxyFactory():this(new ProxyGenerator(),new MethodCallTrackerFactory(new ProxyGenerator()))
        {
        }

        public ProxyFactory(ProxyGenerator proxyGenerator, IMethodCallTrackerFactory methodCallTrackerFactory)
        {
            this.proxyGenerator = proxyGenerator;
            this.methodCallTrackerFactory = methodCallTrackerFactory;
        }

        public IMethodCallTracker<T> CreateMethodCallTracker<T>()
        {
            return methodCallTrackerFactory.CreateFor<T>();
        }

        public T CreateProxyUsing<T>(T instance, IInterceptorConstraintSet constraints)
        {
            return proxyGenerator.CreateInterfaceProxyWithTarget<T>(instance, constraints.AllInterceptors<T>());
        }
    }

People ask me why I love TDD? It’s because you can start with a blank slate, drive out the components one at a time in isolation from another, isolating/deferring responsibilities as you go, and finally you can plug all of the pieces together. In all of the code samples above I added in the poor mans dependency injection so that people could see the concretes being injected into the dependent. In the actual source code, an IOC container is being used. As when driving out the solution the interfaces were used to defer responsiblity to another object that did not exist yet. Taking this code, it would not be hard to add the pre/post/both filter also so that you could choose when specifically to apply an interceptor!! And of course I could eliminate the method call tracker altogether if I made use of lambda expressions and parsed the expression tree to see what method was called. I’ll leave that for another day!!

Develop With Passion!!

After lots of requests, Nothin But .Net is finally coming to Austin,Texas!! I am sure that seats are going to sell out fast, so hurry and register here if you want a spot in what will surely be an amazing week of crazy coding!!

Overview

Nothin But .Net is a five day (intense) boot camp style course that will focus on applying .Net development best practices in the context of developing a working N-Tiered application. Registrants will learn about how to practically apply.Net as they apply it to the task of building a complete application from the UI layer all the way down to the mapping layer.

 

WARNING!!!!

If you are expecting to come to this course to learn about how to have VS.Net automatically generate an “application” for you, then this course is NOT for you.

This course is all about taking control of the .Net framework and having it work the way you want. This course will place a heavy emphasis on getting back to the basics and making .Net do things the way you want it to, in a predictable and testable way.

During the course of the week, there will be absolutely no code that gets compiled from within Visual Studio. Studio itself will be relegated to a glorified code editor. I will teach you development techniques and tools that will dramatically increase your day to day productivity as a software developer.

This course will focus on a code centric view of application development vs. the typical databinding/designer magic covered by many typical .Net courses. You will walk away with a deep understanding of fundamental aspects of .Net and how these pieces can be used to develop and deliver enterprise scale applications.

Core Concepts Overview

        Expand the capabilities of developing with VS.Net - Enter ReSharper (a productivity add-in for Visual Studio .Net)

        There’s more to development than code generators

        Automated Builds       

        Generics ( they’re not just for collections )

        Object Relational Mapping in .Net

        Creating layered architectures

        Driving out functionality and design through testing

        Taking Control Of Databinding

        Test Driven Development & Mock Objects

        Core Design Patterns Applied

 

Detailed Topic Coverage Breakdown

·          Language Enhancements

o    Generics

o    Anonymous Delegates

o    Iterators

o    Linq

·          Collections

o    Taking advantage of the collection interfaces

o    Making use of the IDictionary<T> and IList<T> interfaces.

o    Overcoming the limitations of the IList<T> interface

o    Sorting, searching, and manipulating collections using generic delegates

o    Overcoming limitations of searching with generic delegates

o    Creating custom comparers

·          Events

o    Delegates in depth

o    Creating classes that expose events

o    Safely publishing events

o    Multithreading with delegates

·          ADO .Net

o    Creating a Custom Object Relational mapping layer

o    Effective uses of TransactionScope to test the mapping layer

o    Eliminating the need for stored procedures

o    Effective techniques for querying data

·          ASP.Net

o    Master Pages

o    Passing Data Between Pages

o    Taking Control Of Databinding

o    Validation Techniques

o    Leveraging Front Controller Architecture styles for cleaner separation of concerns.

o    Saying goodbye to WebForms

o    MVC vs MVP vs SC

·          OO Practices & Principles

o    Dependency Inversion

o    Single Responsibility

o    Open Closed

o    Hollywood

o    Tell Don’t Ask

o    Encapsulation

o    Polymorphism

·          Patterns

o    Layered Architecture

o    Data Transfer Object

o    Supervising Controller

o    Passive View

o    Notification

o    Static Gateway

o    Unit Of Work

o    Mapper

o    Gateway

o    Domain Model

o    Null Object

o    Proxy

o    Adapter

o    Abstract Factory

o    Event Aggreagor

o    Service Layer

o    Façade

o    Visitor

o    Decorator

o    Composite

o    Front Controller

o    Notification

·          Testing

o    Using Automated Testing Frameworks

o    Dependency Based/Interaction Based

o    TDD as a design tool

o    Applied Test Driven Development

o    Avoiding over specification problems with Interaction Based Testing

o    Test Partitioning

o    Different types of testing (Integration,Acceptance,Unit)

Recommended Prerequisites

This is an intermediate to expert level course. In order to walk away with the most benefit from the course the following list outlines key prerequisites and the level of knowledge that people would be best served entering the course with:

 

        Knowledge of the C# syntax (Strong)

        Knowledge of the .Net event/delegate architecture (Moderate/Strong)

        OO programming concepts (Moderate/Strong)

        Domain Driven Design (Cursory)

        Refactoring (Cursory)

        Design Patterns (Cursory)

        Automated Testing Frameworks (Cursory/Moderate)

        Test Driven Development (Cursory)

        Utilizing Events and Delegates in .Net (Moderate/Strong)

        Manipulation of core ADO.Net objects (Moderate/Strong)

        Build Automation (Cursory)

 

**********Please be aware that the length of course days (based on prior iterations of the course) can fluctuate dramatically based on the level of student interaction. It is best to come ready expecting the course days to be no less than 10 hours.************

 

Intended Outcomes

Upon completion of this course students should be equipped with a practical, applied understanding of the following concepts:

 

        Interface Based Programming

        Design By Contract

        Test Driven Development

        Layered architecture

        Object Oriented Programming

        Design Patterns

        Unit Testing

        Interaction vs. State Based Testing

        Dependency Injection

        Object Relational Mapping

        Domain Driven Design

        Build Automation

People are required to bring their own laptops capable of running:

• Windows XP w/SP2 & IIS 5.0
• SQL Server 2005 Developer Edition
• Visual Studio 2008 Professional Edition
• TortoiseSVN
• ReSharper 3.x / 4.0

WARNING……………This is a very intense week. Your mind will not have very much in the way of downtime. Days in past courses have gone anywhere from 10 – 20 hours in length!!

One side goal of the course is to leave people feeling a lot more empowered and energized to do their jobs!! Develop with passion is not just my tagline, it is something that I personally believe in!!

If you are interested then sign up here.