Derik Whittaker : Agile

Convention Binding to Ninject 3 -- Resolving ‘Value Cannot be Null’ Exception

Derik Whittaker — Sun, 12 Aug 2012 12:26:00 GMT

Recently I was creating a new MVC4 application and of course I wanted to use Ninject as my IoC container. The first thing I did was to download and install the following NuGet packages:

After I got these setup I opened up the NinjectWebCommon.cs class and started to add code to the RegisterServices method. The first thing i did was to add the code below;

            kernel.Bind(scanner =>
            {
                try
                {
                    scanner.FromAssemblyContaining()
                    .SelectAllClasses()
                    .BindDefaultInterface();

                    scanner.FromAssemblyContaining()
                        .SelectAllClasses()
                        .BindDefaultInterface();

                    scanner.FromAssemblyContaining()
                        .SelectAllClasses()
                        .BindDefaultInterface();
                }
                catch (Exception e) // added to try to get the exception message
                {
                    Debug.WriteLine(e);
                    throw;
                }
            });

The above code would step over the first scanner call w/ no issues, in fact if that was the ONLY statement it all worked as expected, however when it stepped onto the second scanner. call I would get the following error.

System.ArgumentNullException: Value cannot be null. Parameter name: first

Because I knew everything worked fine with only one scanner. call i decided to give it a go w/ creating a unique kernal.Bind for each assembly i wanted scanned as below:

            kernel.Bind(scanner => scanner.FromAssemblyContaining()
                                       .SelectAllClasses()
                                       .BindDefaultInterface());

            kernel.Bind(scanner => scanner.FromAssemblyContaining()
                                       .SelectAllClasses()
                                       .BindDefaultInterface());

            kernel.Bind(scanner => scanner.FromAssemblyContaining()
                                       .SelectAllClasses()
                                       .BindDefaultInterface());

This did the trick, I could now setup the bindings for multiple assemblies with no issues. So it appears that with this version of the Extensions class for ninject you need to do each action as a unique .Bind method.

Till next time,

Testing that EventHandlers were wired up correctly with NUnit and Rhino Mocks

Derik Whittaker — Tue, 24 Aug 2010 11:04:04 GMT

Today I was trying to wrap some code in some tests (I got lazy and did not create the tests first… shot me). What I was trying to ensure was that my event handlers I passed into a method were actually being wired up for usage. Now I searched around the net for a while to see if there was a elegant solution to this problem but I could not find one. Below is the solution I came up with. Mind you this may not be a great solution, hell it may just down right suck but it works for me.

First things first, her is the method i was trying to provide coverage for

public void GetAppointments( DateTime? from, DateTime? to, 
    EventHandler localRequestStarted,
    EventHandler remoteRequestStarted,
    EventHandler> requestFinsished )
{
    var currentUser = _sessionManager.GetValue();
    var dataRequest = new AppointmentDataRequest( new AppointmentParameterContext( currentUser.ResourceIds, from.Value, to.Value ) );

    dataRequest.LocalRequestStarted += localRequestStarted;
    dataRequest.RemoteRequestStarted += remoteRequestStarted;
    dataRequest.RequestFinished += requestFinsished;

    _dataManager.Fetch( dataRequest );
}

As you can see there are 3 lines in the above code where the passed in EventHandlers are being attached. I wanted to ensure this. But what you may also see is that I have no direct access to the dataRequest object which is being created in this method. That is where our handy rhino mocks library comes in. With Rhino Mocks I am able to get the pointer to the various values which are passed into methods. Check out the test below and you will see how this is done.

My unit test

[Test]
public void GetAppointments_WhenCalled_EnsureWillWireupEventsCorrectly()
{
    var dataManager = MockRepository.GenerateMock<IDataManager>();
    var sessionManager = MockRepository.GenerateMock<ISessionManager>();

    var currentUser = new CurrentUser();
    sessionManager.Stub( x => x.GetValue<CurrentUser>() ).Return( currentUser );

    var provider = new AppointmentProvider( dataManager, null, sessionManager, null );
    bool localWired = false, remoteWired = false, requestFinishedWired = false;

    EventHandler<LocalRequestStartedEventArgs> localRequest = ( s, arg ) => { localWired = true; };
    EventHandler<RemoteRequestStartedEventArgs> remoteRequest = ( s, arg ) => { remoteWired = true; };
    EventHandler<RequestFinishedEventArgs<object>> requestFinished = ( s, arg ) => { requestFinishedWired = true; };

    provider.GetAppointments( DateTime.Now, DateTime.Now, localRequest, remoteRequest, requestFinished );

    IList<object[]> argumentsForCallsMadeOn = dataManager.GetArgumentsForCallsMadeOn( x => x.Fetch( Arg<DataRequest>.Is.Anything ) );

    var dataRequest = (AppointmentDataRequest)argumentsForCallsMadeOn[ 0 ][ 0 ];

    dataRequest.RaiseLocalRequestStarted();
    dataRequest.RaiseRemoteRequestStarted();
    dataRequest.RaiseDataRequestFinished( DataRequestType.UserLogin, DataRequestResult.Unknown, null, null );

    Assert.That( localWired, Is.True );
    Assert.That( remoteWired, Is.True );
    Assert.That( requestFinishedWired, Is.True );

}

As you can see this test has a lot going on, but let me explain some of this for you.

1) First thing we need to do is create a few local variables which will hold the state of the event firing

2) Next we want to create local copies of our event delegates in order to push them into our method

3) Next is time for the Rhino Mock magic. Notice how I am calling the GetargumentsForCallsMadeOn() method. This is a method in Rhino Mocks which allows me to reach into the call stack and pull out the values which were pushed into a method when it was called. I then cast the argument i want to its native type.

4) In order to ensure the events were wired up I need to call the various ‘raise’ methods in order to trigger them. Doing this should cause my local state holders for the events to be changed and this is what we actually want to ensure

5) Ensure the event state variables were set to true.

There you have it, a simple (well kinda) way to ensure that your events have been registered correctly in your code.

Till next time,

Do you have an Action Plan to Tackle your Technical Debt?

Derik Whittaker — Fri, 09 Apr 2010 11:20:33 GMT

As a general rule all software development teams will create technical debt during the construction of their product. Creating this debt is in no way an indicator that the team is bad or not talented, but rather is an indicator that they understand that there are always tradeoffs when building an application. The fact of the matter is we are in the business of building applications which need to get to market and while building these applications we will be faced with decisions about trade off's.
Now I stated that creating technical debt is not any indicator of talent, but I will say that not creating an action plan to resolve this technical debt is a major indicator of experience. All software teams must maintain a list of items (non-business features) that need to be addressed at some point in the future. They need to mandate that this list be reviewed on a regular basis and priority be put on each item along with an action plan.

What counts as technical debt? .... Anything :) No really:

Design trade offs you make
Areas in code which could be simplified by the addition of a new tool or library (this may not have been a technical trade off at the time of construction, but new libraries could simplify the code.
Areas in code 'that are not to be touched for fear of breaking' (you KNOW your projects has these dark corners)

Why Technical Debt is created?

When faced with a decision in regards to 'simple, quick, easy but not the best' or 'longer, more complicated but right' many times we reach for the 'easy button'. Reaching for this easy button is ok, but only as long as you understand the tradeoffs.

Deadlines loom and we 'cut to finish'.

Poor decisions were made by the team

The team lacks the experience to make good decisions (not normally the case, but it can be)

Why Technical Debt is a burden on your project?

It creates roadblocks for new development
Can increase complexity in your codebase making new features more difficult to create
Causes re-work to be performed in the future, which could take longer than had it been done 'right' in the first place

Why having the list is a good thing?

Keeps the list visible and if it is visible it will receive attention
Keeps people informed of bad (potentially bad) tradeoffs which were made in the past
Keeps people informed of potential refactor points

Why having the list is a bad thing?

Admits to others (especially management) that your code may have flows (I actually see this as a good thing, but others do not)

Reminds you of all the bad decisions you made... wait that is bad... NO

How we maintain our action plan for Technical Debt?:
Our team has created a list in our team wiki and grouped the items in the list by product feature. Each team is expected to add items to this list as they come across items in code which need to be addressed in the future.

When we add our items we provide the following level of information:
Short Description:
Original Reason for the debt (if known):
Risk of change: (high, meduim, low)
Risk if not changed:
Action Plan:
Date/Release Debt removed:

At the end of the day the code you build is the code you are going to be required to maintain over the long haul. If you make the decision to not activily address your technical debt not only will your pain increase while working on your codebase but your customers will start to suffer because the cycle time to create new releases will increase and new features will flow slower and slower.

Till next time,

Depends vs Call, Do you know and understand the difference in NAnt?

Derik Whittaker — Fri, 20 Nov 2009 11:32:00 GMT

This past week I was taking a look at one of our build scripts as it appeared to be taking a bit longer than everyone wanted. Because I am very close to the file (authored about 50% of it) I decided that in place of just diving in and looking at the raw source I would instead run the script with the given options I needed and record the output (nant.exe -buildfile:Demo.xml SomeTargetName > Log.txt) and once the run was complete I would take a look at the output and look for ‘out of normal items’. Within a few minutes of scanning the file I noticed something ODD, we were compiling all of our code twice (just to be double sure it compiled correctly of course).

Now that I knew the issue, double compiling 5 solutions for each build, it was time to determine why we were doing this. As I started to follow the call chain I noticed something that was a bit interesting to me. It appeared that were we calling a target via a <Call> command vs a Depends command the entire call stack would be re-executed. A quick google search lead me to this page (here) which had the answer to my problem. Per the Nant documentation:

A target gets executed only once, even when more than one target depends on it (see the previous example). However, when the <call> task is used to execute a target, both the target and all its dependent targets will be re-executed.

Hum.. problem found, root caused determined. Now it was simply a matter of resolving the issue. SWEET

To better illustrate this scenario I have created a simple example (with screenshots to boot).

Imagine you have the following Nant script (sorry, could not get the XML to not be ‘xml’ and rather be code/text)

If you take a look at the script above you will see 2 things.

I have a few targets that use Depends to call other targets
I have one target (Target_Z) which simply does a call out to the other targets it needs

In order to understand how ‘Depends’ works and the fact that it will NOT double call a target lets take a look at the call stack if we invoke Target_A directly.

As you can see from the image, each target is only invoked once even though that Target_C is referenced by both Target_A and Target_B

Now, to understand how ‘<Call>’ works and the fact that it will double call targets let take a look at the call stack if were to invoke Target_Z directly.

As you can see from the image above, Since Z calls both A & B we get the repeating of each of their targets, so Target_B and Target_C are each called multiple times and this could be really bad on performance.

Now that you understand the difference between <Call> and ‘Depends’ use this information wisely and with caution.

Oh, by not double calling our compile for all 5 solutions we shaved about 4-5 minutes off of our CI build… NOT TOO BAD

Till next time,

Simple Kick Start Example using MEF (Preview 8)

Derik Whittaker — Tue, 27 Oct 2009 10:34:00 GMT

If your application needs extension points what do you do? Building a plugin based system is not cutting edge, it is not rocket science. However, it does take a little effort and can be a bit painful depending on your implementation. The guys at MS (Glen Block and crew) has been working on this kickin framework for about a year now called the Managed Extensibility Framework (most commonly known as MEF). The core goal of MEF is to simplify the creation of extensible applications. MEF offers discovery and composition capabilities that you can leverage to load application extensions.

There are a metric crap-ton of samples out on the net which show how to get running with MEF, however many of the posts are based off of older previews and most are also incomplete in terms of the code they show you on screen. What I would like to do is provide a detailed how-to on getting your first (simple) MEF application up and running.

Goal of the demo code?
For this demo code we are going to put together a very simple rules plug-in engine. The goal is to be able to add in a new IRule at any point and have your application pick it up.

What is needed?
If you have not already done so head out to http://mef.codeplex.com/ and grab the latest source download. More than likely you will need to download and compile all the source in order to get working binaries (hey, it is a preview after all). Once you have compiled the source you need to grab the output from the ComponentModel project (assembly name is System.ComponentModel.Composition) and include this into your project.

Putting it together?

Creating the rule Interface : IRule
This is needed because in order to define a plug-in you need to define what that plug-in looks like.

public interface IRule
{
    void DoIt();
    string Name { get; }
    string Version { get; }
    string Description { get; }
}

Creating a rule instance (or two)
Now that we have our rule interface we need to create specific instances of the rule and mark them for export. Marking them for Export simply entails adding a attribute provided by the MEF framework and this attribute allows you to describe your plug-in to the MEF framework so it can pick it up.

[Export( typeof( IRule ) )]
internal class RuleInstance1 : IRule
{
    public void DoIt() {}

    public string Name
    {
        get { return "Rule Instance 1"; }
    }

    public string Version
    {
        get { return "1.0.0.0"; }
    }

    public string Description
    {
        get { return "Some Rule Instance"; }
    }
}

[Export( typeof( IRule ) )]
public class RuleInstance2 : IRule
{
    public void DoIt() {}

    public string Name
    {
        get { return "Rule Instance 3"; }
    }

    public string Version
    {
        get { return "1.1.0.0"; }
    }

    public string Description
    {
        get { return "Some Rule Instance"; }
    }
}

Creating the holder for all your plug-ins
In order to have your application know about the plug-ins that MEF has found you need to define a storage location for them. We will do this by creating a property of IList<IRule> which will hold each instance. When we create this storage location we need to tell MEF that we are going to use this as a storage location and to do this you need to mark it with the ImportMany (use this attribute if you want a collection, use Import for only a single instance) attribute. This is another special attribute provided by the MEF framework.

[ImportMany( typeof( IRule ) )]
internal IList<IRule>: _rules { get; set ;}

Creating the logic to load the plugin
Now that we have all the heavy lifting out of the way in terms of defining our Imports and Exports it is time to setup our application to consume the data. It is here where you tell MEF where to look to find your exports (plug-ins) and what to do with them once you have found them.

public void Init()
{
    var catalog = new AggregateCatalog();
    var container = new CompositionContainer( catalog );
    var batch = new CompositionBatch();
    batch.AddPart( this );
    // because all our types are in the same assembly we simply use the current one.    
    catalog.Catalogs.Add( new AssemblyCatalog( Assembly.GetExecutingAssembly() ) );
    container.Compose( batch );
    foreach ( var rule in _rules )
    {
        Debug.WriteLine( rule.Name );
    }
}

Wrapping it up
As you can see getting a simple example of MEF up and running is a pretty simple task (great job MEF team). You should be able to get this up and running in about 10 minutes. You should also have all the code you need in order to get this running. I hope this helps kick-start someone’s learning and adoption of MEF.

Till next time,

Testing only the code of value

Derik Whittaker — Wed, 07 Oct 2009 11:48:25 GMT

I am 99% sure I have had a post like this in the past, but my google-foo was weak today and I could not find it. Do not let anyone blow smoke up your back side, testing is expensive, testing takes time but most importantly testing can help improve the quality of your code.

If you are going to spend the time and money to create automated, rerun-able unit tests make sure you spend your time/money wisely. Make sure you test the code that matters, test the code which is complicated (keep in mind a LOC count does NOT equal complexity).

Today when scanning some code in another part of our project I came across this tests:

public void AdminSetIDTest()
{
	var target = new CreateTaskActivity();
	int expected = 50;
	int actual;
	target.AdminSetID = expected;
	actual = target.AdminSetID;
	Assert.AreEqual(expected, actual);
}

When I looked at this tests 2 bells immediately went off in my mind

The name of this tests SUCKS BALLS and does not clearly convey the intent of the test
This is testing that a property getter works (no, there is NO logic behind the getter/setter)

If you disregard #1 from above for now (but remember clear/concise names do matter) and focus on #2 this tests adds no value to the test suite. All this test is doing is ensuring that the .Net framework does its job. This test is a total waste of time and energy and can actually cost you more time/money in the long run because you may have to change the useless test over time as you refactor.

The key take away from this is simple. You always have limited time and money when trying to get a product out the door. Unit testing IMO can always help you to create a better product, but make sure you use your time and money in a way in which will allow you to maximize your ROI.

Till next time,

Your unit test may smell if…….!

Derik Whittaker — Wed, 09 Sep 2009 17:28:30 GMT

If you find yourself using reflection in your unit test to push 'stub’ data into it your test just may smell. Now there are times (especially when dealing with legacy code) that you need use reflection to crack open a class to push/pull values but I would strongly suggest you consider the solutions I am going to suggest.

Utilizing the wrap method (see Working with Legacy Code) to accomplish your goal.

Lets assume you have the following class which you want to test:

  public class SomeClass 
  {
    private DateTime _lastVerified;
    private DateTime _lastActivated;
   }

Now one way to push data into these fields would be to do the following:

    [Test]
    public void IsTimeToActivateTrueLastActivatedTheDayBeforeCurrentTimeAfterActivationTimeTest()
    {
      SomeClass accessor = new SomeClass 

      Type type = SomeClass 

      FieldInfo field2 = type.GetField("_lastActivated", BindingFlags.Instance | BindingFlags.NonPublic);
      field2.SetValue(accessor, new DateTime(2008, 2, 29, 10, 5, 0));

      FieldInfo field3 = type.GetField("_lastVerified", BindingFlags.Instance | BindingFlags.NonPublic);
      field3.SetValue(accessor, new DateTime(2008, 3, 1, 10, 0, 0));
    
      DateTime currentDateTime = new DateTime(2008, 3, 1, 10, 10, 0);

      MethodInfo method = type.GetMethod("SomeMethod", BindingFlags.Instance | BindingFlags.NonPublic);
      object result = method.Invoke(accessor, new object[1] { currentDateTime });

      bool isTime = (bool)result;

      Assert.AreEqual(true, isTime);
      Assert.AreEqual(currentDateTime, field3.GetValue(accessor));
    }

Now this works, but if you do this over and over again you will kill yourself with reflection code.

Option 1) Create a subclass of your class and hide the reflection inside your subclass

public class MySubclassOfSomeClass : SomeClass
  {
    public void SetLastActivatedTime( DateTime value )
    {
    	// set the value via reflection here
    {
	
    public void SetLastVerifiedTime( DateTime value )
    {
    	// set the value via reflection here
    {
   }

The code above will still use reflection to set the value, but it will hide the usage of reflection from your unit test and will present a less noisy test to future developers

Option 2) Change the scope of the fields and subclass and extend

  public class SomeClass 
  {
    protected DateTime _lastVerified;
    protected DateTime _lastActivated;
   }

public class MySubclassOfSomeClass : SomeClass
  {
    public void SetLastActivatedTime( DateTime value )
    {
    	_lastActivated = value;
    {
	
    public void SetLastVerifiedTime( DateTime value )
    {
    	_lastVerified = value;
    {

If you change the scope of the fields to protected you could subclass the original class and do the same as option 1, but because you have access to the fields via inheritance there is no need to use reflection.

So, remember that tests are code to and if you feel pain writing test you may be doing it wrong.

Till next time,

Quantity is NOT a measure of Quality

Derik Whittaker — Fri, 21 Aug 2009 14:08:15 GMT

Today I was asked what I thought about asking each of our feature teams to report the total number of new unit tests created during their iteration. My knee-jerk reaction was to ask the person WTF were they thinking. However, my better sense (yea, I have a little common sense) kicked in.

Before I started to explain my point of view, I asked the person what the intent of this requirement was? Their reasons were below:

With this in place it will keep the developers inline in terms of knowing that creating tests is important
More tests == more coverage which SHOULD increase code quality
Simple measurement tool to track work items

Once all the points were stated, only then did I state my view.

Reason: With this in place it will keep the developers inline in terms of knowing that creating tests is important
I am ok with this being a goal as it is important for each developer to clearly understand what is expected of them when creating code. However, I would rather show them why creating unit tests should lead to better code with less bugs rather than force them to write tests or else.

We as a profession need to start taking the stance that we must convince or persuade developers, but rather show them why one way may be preferred or better.
Reason: More tests == more coverage which SHOULD increase code quality
In general principle I agree with this statement, however unit test count is NOT a good measure. Here is why:

I could spend 2-3 hours creating a single unit test that proves out a extremely critical path in code which adds great value or I can spend 2-3 hours created 20+ test that add little to no value. It is because of this single fact that count of tests (like lines of code count) can be a very, very useless measure.
Reason: Simple measurement tool to track work items
Well, I guess there is only one thing I could say for this one….When should I turn in my TPS reports

Anyway, If you are reading this and can take anything away, it should be this. Measurements are good, but make sure you are measuring the right metric. In terms of measuring code, lines of code and count of tests may not be the best measurement.

Till next time,

Tests are not ‘Tasks’ you put on a backlog…

Derik Whittaker — Tue, 28 Jul 2009 00:57:50 GMT

Today I had a conversation with our ‘scrum of scrum’ masters (we have 7 different scrum teams on our product team of 60+) and he asked me why someone would provide ‘developer tests’ as a task for the backlog?

Before I go any further, this is NOT a bait type of email, simply my opinion. If you do not buy into the testing (either TDD or test after) then you can disregard this post. But if you do buy into the testing concepts keep reading.

In order to gain a better understanding of the context I asked my SoS master for more background on this project and what they were doing. After a brief conversation I became very clear to me that this developer did not think of testing as part of his requirement of building out a feature, but rather as a stand alone deliverable that he needed to deliver at the end of the sprint.

I explained that all developers on our team need to stop thinking in this way and to start looking at tests as ‘first class citizens’ when creating code. I believe the exact statement I gave him was:

When developers are creating a feature, the unit tests which prove the feature as being valid is just as critical as the code which implements the feature.

Quite simply, IN MY OPINION if you buy into the testing concepts stop thinking about tests as a second class citizen and start thinking about them as part of your deliverable.

Till next time,

Throw away and rebuild or refactor from within

Derik Whittaker — Mon, 13 Jul 2009 19:39:19 GMT

The other day on Twitter there was a stream whether it is better to completely scrap an applications code base and start over, or refactor from within. Now I do want to state right now:

The information here is based on my experiences and is simply my opinion. I know this is almost on par with the average biblical debate so lets just agree to disagree now.

Anyway, now that I have put on the standard disclaimer lets continue on with the post. As I stated there was a debate on which was better, rewrite or refactor…..

Once upon a time I thought that without a doubt that rewriting that crap filled, unmanageable and unextendable code was the ONLY way to succeed. However, during my career I have come to the conclusion that rewriting was actually the wrong decision and refactor from within is the right one. Here are some of my thoughts as to why

Re-Writing
Pros:

You get to scrap that old code that smells.
You get to build a better, more maintainable architecture going forward.
You get to use the latest technologies and this is always the best thing.
We know the business better now, this will allow us to create a better, more flexible application

Cons:

Is the business going to actually stop innovating or changing long enough to let you completly rewrite the application? NO
If they are not going to stop moving forward this means there is going to be a maintance team doing this type of work. This means you are coding against a moving set of requirements that will change daily… FAIL
What makes you think that you can write it better the second time around? If you wrote unmaintable crap the first time why do you think you are better now (ok, assuming you did write it the first time).
More than likely you are simply going to pile on the latest tech because you can. Because you are an ego freak and the only way to write good code is to use new tech

Refactor from Within
Pros:

You have the ability to continue delivering new versions of the application with new features.
You actually increase your knowledge of what ‘crappy’ code looks like and how to fix it.
You can learn how to refactor your legacy code with minimal risk and learn how to do it a way that allows you to deliver new code

Cons:

This is NOT easy
This is NOT slow
There is always the thought that you will never actually be complete and that the refactor effort will be dropped at some point in the future. If this is true, rest assured that your application will be better off anyway.

Ok, there you have it, my list of pros/cons for each (this is not an all encompassing list, just some of my random thoughts). In my opinion the refactor is a better, safer choice. But this is not as sexy and takes a ton more effort and patience. However, I believe in the long run you will be better off.

Till next time,

What I expect my Continuous Integration server to do for me.

Derik Whittaker — Fri, 05 Jun 2009 01:02:00 GMT

Recently I had a post where I made the statement ‘To CI or not to CI, did not realize it was still even a question?’. The intent of the post was to assert that I did not realize that having some sort of CI (Continuous Integration)/Build Server was not considered the norm for a development shop. I that post I stated that your CI setup could be as simple as a cron job running a script or be a full fledge product such as Team City, Hudson or CC.Net.

Since I went out and did a rant about how there was no excuse for a team to NOT have a build server I thought I would put together a post on the various things I would expect to see from a CI server. Now I am NOT saying that if your CI setup does not do all these things you are doing the right thing. What I am saying is that the list below (and I am sure I will miss something) are some of the things I expect my CI setup to do for me (in no real particular order).

Monitor my source repository and build on changes
Run my unit tests
Run various static analysis metrics
- Code Coverage
- FXCop/Style Cop
- Any of the metrics from NDepend
Publish assemblies for usage (could be to a test server, a file server or ftp server)
Build a clean copy of the database from my setup scripts (we have a running list of alters we use to perform upgrades)
Be able to commit versioned assemblies back into the repository for other teams to use (if that is something your team needs)
Create some sort of visual graphs/trends for tracking
Be able to run a build which creates and packages an installer (for deployment)
Send notifications (emails/post to discussion boards, twits, etc) when there are issues

Now I know this is an extensive list. I also know that trying to do all of these things at one time is both daunting and not practical. But these should be the goal. What I will say is this, start small and build. Your goal should be to incorporate these things into your build over time and if htat is your goal you will be amazed what happens.

Happy building

Till next time,

To CI or not to CI, did not realize it was still even a question?

Derik Whittaker — Tue, 19 May 2009 20:22:44 GMT

Over the past few weeks I have been presenting at a few .Net user groups and one of the questions I asked prior to each session was the number of people who have some sort of CI/build server for their team. Now keep in mind I qualified this question by stating that this build server could be a cron job, a build script of some sort or a full fledged CI product (team city, Hudson, TFS, etc).

I continued to be amazed by the number of people who have no CI type of process on their teams. I thought (and I ~~guess~~ know that I am wrong) that having some way to ensure your product builds and integrates was just common sense.

It is little things like this which keeps our profession in the dark ages. To all the shops out there who do not have a CI process. GET OFF YOUR ASS AND BUILD ONE.

<RANT>
I’m sorry, but if your team does not care about the little details which make your product better what the hell makes you think you will get the big details right?

Ok, before anyone flames this post with ‘we can do CI because…’ I have a few items

Use free products (NAnt, CC.Net, Hudson, NUnit, etc)
Start simple. Only compile your code… screw the rest
It does not take that long, really it does not. A complete noob should be able to get a simple Nant script running as a hourly process in a single day

</RANT>

Ok, rant over. Really, if your team does not have a CI process add one. You WILL thank me for it in the long run.

Till next time,

Teaching someone to test using an Isolation Framework

Derik Whittaker — Tue, 30 Dec 2008 17:21:12 GMT

Part of my job at work is to teach and mentor other developers on our team. Right now I am in the process of teaching two of our developers how to create unit tests (notice I did NOT say integration tests because most anyone can do those). We are also learning how to create our tests by utilizing an Isolation Framework (aka mocking framework).

I am really excited for this opportunity because I firmly believe that you create better software when you do it by creating tests to prove your code works. I am also excited because both of the developer buy into the idea of testing and are extremely eager to learn how to to better test their code.

Because we had a few days of downtime because of the Christmas holiday before our 1st sprint on our project we thought it would be a good time to do some pairing (guess it would be better called tri-pairing). Our plan of attack was to start to flush out some of the features in our system but do it in a total TDD manor. We were also going to be utilizing the Rhino Mock Isolation framework in our tests.

So over the next 2 days we spent about 12 hours or so working building out our code. Over this time we actually were able to create an complete end to end 'version' (I say version because we did not fill in all the functionality of the code but were able to get all the major pieces stubbed out) which allowed us to flush out many, many more business requirement and build a simple, yet flexible code base.

I hope both of my co-workers learned a ton from this exercise, I know I did. This was the first time where I had actually spent any significant amount of time teaching someone who was new to testing how to do so. Sure I had spent an hour here or an hour there, but nothing like this.

What I really wanted to share with everyone is what I learned form this experience.

Slowdown, slowdown, slowdown
The first thing you should do when teaching something how to do anything is SLOWDOWN. You have to remember that if you are talking/teaching to someone who is new to this they have to not only try to process the information so they can understand it, they also have to try to remember it.

Make NO assumptions, teach as if they know nothing
This one was the most important thing I learned. You cannot make assumptions on anything. Anytime you say anything make sure you fully explain it. If you use an acronym EXPLAIN IT. Any time you mention a buzz word EXPLAIN IT. Plan and simple EXPLAIN EVERYTHING

Have them drive
During the teaching part it is critical that you have then code, have them tell you what to do. It is ok for you to 'lead' them in the right direction, but you must not always drive. This will really help to drive home the concepts.

Provide examples both with and without the Isolation framework
In our case because I was trying to teach them testing using an Isolation framework it really helped when I would create a test (aka integration) with no mocks and then re-create it with mocks. Doing this really helped to explain to them how using the Isolation framework removed dependencies.

Don't let them skate by
Don't let them simply nod their head as if they understand. Make sure you keep asking them if there is anything you can clear up or explain better. At first they are going to simply say no, they are good. But as you keep asking and start having them drive they WILL start to ask more questions, I promise.

Turn off any coding tools such as ReSharper (or the likes) and do NOT use shortcuts
This may have been the biggest issue for us at first. I am pretty good with ReSharper (if I can toot my own horn here) and I was coding with it as I would do if I were by myself. On more than one occasion the would look at me cross-eyed and ask 'what the hell just happened'. Finally I simply stopped using it for the first day. On the second day I went back to using R#, but I turned on Keyboard Jedi so they could see what was going on. Even though I turned on Keyboard Jedi, I tried my best to make sure to explain what just happened when used R#.

Anyway, I have rambled on long enough and I think I have pretty much gotten my thoughts out there. I really enjoyed working with these guys and I am looking forward to doing so again when we get back from break.

Hope this helps,

Till next time,

StructureMap and Loaded Plugins Gotcha

Derik Whittaker — Fri, 19 Dec 2008 02:33:14 GMT

One of the really great things about the latest release of StructureMap is that I do not need to register objects by default if they follow a standard convention (i.e. if I want to register a controller called ‘AuthorController’ and accessed via ‘AuthorController’ I do not need to do anything, SM is smart enough to map this for me). However, as great as this is, there is one slight issue (may be a bug, do not know need to follow up with Jeremy).

In the Dimecasts codebase I put the logic to register routes for each controller into each controller. I then at startup time I loop though all the controllers and register each route.

The code below is the logic I do for performing this registration

	
	var controllerInstances = ObjectFactory.Model.PluginTypes.Where(x => typeof(BaseController).IsAssignableFrom(x.PluginType));

	foreach (var controllerInstance in controllerInstances) 
	{ 

	var instance = (BaseController)ObjectFactory.GetInstance(controllerInstance.PluginType); 

	instance.RegisterRoutes(RouteTable.Routes); 

	}

All of this works and works well but when i added a new controller to the application and did not manually register it (aka using the convention of configuration feature) I was not able to load the new controller. I was a little stumped at first, but then it downed on me that since i am not pre-registering the controller with StructureMap it may not now how to find it. To test this theory i simply manually registered the controller and bam, all worked.

I thought I would share this incase anyone else had the same issue.

Till next time,

[--- Remember to check out www.dimecasts.net ---]

Testing is hard but debugging just sucks A$$

Derik Whittaker — Fri, 14 Nov 2008 23:58:05 GMT

In my last post (here) I was giving a wrap up of the Mocking session I recently did at TriNug. In that post I gave some of the reasons (sorry, I meant excuses) people gave for not doing any type of automated testing during their dally development ritual (notice I am staying away from TDD at this point). I thought that those topics would be better suited to be broken out into their own post.

At the users group I asked the question to the group 'who creates automated tests as part of their daily development cycle?'. After I asked this question I followed it up with, and if you don't WHY, WHY, WHY, WHY...... Below are some of the answers I received (btw, not the first time I have heard these reasons).

Reason #1 - It is too hard to get started:

Point: This statement is nothing new, I hear this all the time. To be honest I agree with them, testing is hard. It takes time and effort to learn how to do it.

Counter Point: But if you think learning to write tests and learning how to create testable code is hard, then what do you do when you need to learn a new product? I can break it down like this. Testing == Coding and Coding == REAL FREAKING HARD. Stop using 'testing is hard' as a crutch and just give it a shot.

Reason #2 - My client/company is not paying me to write tests:

Point: This one always make me laugh. Since testing does take time (not going to sugar coat this at all), and can slow down your pace of development, many people feel that they are not being paid to create tests.

Counter Point: This one is real simple, ask your self these two questions.

Am I being paid to produce quality or crap?
Am I being paid to debug?

I am going to assume that both of those answers are NO, and if they are not then I would suggest you stop reading this post as it does not get any better from here.

Now that we are on the same page and we understand you are being paid to produce quality code why would you not want to do everything you can to bake that quality into your code up front? This can happen with tests. Take the time, take the challenge and create some tests. Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint (and if you do get fired because of it just look at it this way, you have a new and marketable skill to help you find your new job).

Reason #3 - I do not have time

Point: Testing takes time, and when time is short people throw every 'non-critical' functions out the window. And sadly people think that quality is a non-critical function. To prove this point just take a look at 90% of the applications out there... they suck ASS

Counter Point: Just ask yourself this question. Would I rather spend what little time I have creating tests to help ensure I have quality or would I rather spend time later stepping through code via the debugger looking for the bug I could have caught/fixed earlier? If you would rather spend time in the debugger, then more power to you.

NOTE: Do NOT take the above statement as me saying that testers NEVER debug, they do but just a TON less than others.

Reason #4 - My code will not allow me to tests

Point: This is one may be the only excuse that has some merit. Poor code is hard to test.

Counter Point: Simply because you do not need to retrofit your entire code base at one time. If you have 'bad' code that is easy to test that is fine. Start testing with NEW code. Hopefully you will not be creating bad code once you understand your current code is not the best. You will also come to understand that when you start testing your code will start to get a little cleaner. Finally, if you really want to start to test your legacy code, go out and pick up 'Working Effectively w/ Legacy Code' by Michael Feathers

As you can tell from my tone, I do not buy into any of these reasons, sorry excuses. I wish that when I ask people this question and they gave me a response they would simply state the truth. And the truth is people do not test for the following 2 reasons

Reason #1 - They do not believe that creating tests will improve their code
If this is what you really think, that is fine. You are allowed to have your beliefs and I am allowed to have mine. As long as we understand each other we can get along just fine.

Reason #2 - They are lazy
Not sure I need to explain this one.

Let the flames begin :)

Till next time,