The idea is quite simple, but very powerful.  Allow a select group of employees to participate in a competition for creating the most innovative feature.  The catch?  It must be fully shippable within 24 hours.  Hence, the term FedEx Days.  Very clever!  And from the results they report at Atlassian, far more than just clever.  They’ve been able to achieve some very sophisticated feature improvements based on this model.  Apparently, the combined elements of competition and a fixed time constraint are key ingredients to achieving that innovation spark that’s often missing on extended projects.

So, if your team is stuck in a rut, consider giving this approach a try.  You can offer real prizes (free beer, cash, trophies), benefits (additional vacation days, prime parking spot, name on the company newsletter), or just good old fashioned bragging rights.  Lots of potential here, and it doesn’t have to be expensive.

PS: For a great demonstration as to why this works, check out this video!

The hope which Mr. Hill so generously points out to the readers of his time is the same hope that is available to us today, despite persistently high unemployment, a stagnating  economy, and the ineffectiveness of governments around the world to do anything about the economic woes that continue to plague us.  What is this great hope?  It certainly is not government benefits.  It isn’t even better education or job training.  This hope consists of two key ingredients – DESIRE and FAITH.  And these ingredients are not restricted based on race, gender, color, creed, disability, age, or any other limiting factor of which we are prone to complain.  They are literally free to all.

Mr. Hill had no way of knowing how men like Steve Jobs or Bill Gates would transform the world.  These men, and others like them, generated literally billions of dollars in wealth for themselves and people all over the world from one simple raw material – the incomprehensible power of ideas.  And these are a just a couple of examples – volumes could be written containing the stories of thousands of others just like them.  Consider this question: Which has produced more wealth – the diamond mines of Africa, or the digital ecosystem that was created by the advent of the Internet?  It’s not even close!  Far from running out of resources, we stand on the shores of a vast digital ocean that has only begun to be explored, much less mastered.

So, the next time you are tempted to allow a little laziness to slip in and excuse it away by blaming the bad economy, remember this statement from Napoleon Hill.  And remember that others have faced far worse times than we, and not only overcame, but built tremendous fortunes and lasting legacies.  You are without excuse – the DESIRE and FAITH that empowered Andrew Carnegie to build his empire, or Henry Ford to build the V8, or Steve Jobs to revolutionize the way we consume media – these ingredients are freely available to you and I today.  Let’s settle it right now, and determine to tap into that vast resource of ideas.  The solutions to our worldwide economic woes are no further away than that grey matter between our ears.  Let’s get to work!

So, here is the finished code for this first test:

Very, very simple!  Unit tests should not be too long.  If they are, then it’s probably because you’re testing too many things.  So, just as the test name implies, I’m feeding my controller bad data intentionally, and then checking the results of how my controller handles that data.  I expect to get an exception, so let’s look at the controller code:

Since I know the MVC framework will handle creating a DateTime object from the data passed in via the query string using a parameter of the same name, I really only need to test whether or not a date was passed.  My controller logic requires a start date, and an end date, and the end date must be later than the start date.  So for this first condition, I check for an empty date.  If I received an empty date, I throw a special JsonException.  You can see that in the catch block for JsonException, I do the following:

• Log the exception – all exceptions should always be logged
• Set the status code to be returned to the ajax call, letting the javascript know an exception occurred
• Return a JsonResult view, containing the exception to be passed back to javascript

I also include a default catch block to handle any unexpected exceptions in the same way.

With this done, my test will now run and pass.

That concludes one iteration of the process.  I can now check this code in!  It will not break the build, it’s legitimate (though incomplete) code.  Repeat this process for the remaining conditions, such as:

• Test the end date parameter
• Test that start date and end date are correct with respect to each other (i.e. end date comes after start date)
• Test that a valid logged in user initiated the request.

After all of the tests for bad data conditions are finished, the last thing to do is write a test for the valid case.  With all of these steps completed, you now have a solid, reliable, repeatable way to test this controller.  When it comes time to refactor this controller, you can do so with confidence, knowing that this path through the code will always be exercised automatically when the code is checked in to the central repository.

Most of my applications make use of the Repository pattern as the portal through which interaction with the data store occurs.   Using this approach, I can provide a standard access interface that allows my controller to make one call, and it doesn’t matter if it’s calling into a fake repository or the live repository – the controller logic works the same in either case.  The beauty of this approach is it allows me to construct a fake repository in memory, which has several advantages:

• It is extremely fast
• It is always initialized into a known state – I don’t have to write database setup/teardown code
• I don’t even have to have access to the database

So, with that said, my first step in making my test pass is to give it an instance of the fake repository, like so:

I instantiate the fake repository in the Init call, so the repository is alway rebuilt prior to executing the test.  That way, if my test makes changes to the repository (i.e. inserts a record, changes a field, etc.) the repository is always returned to a known state before the next test begins.

The next step is to setup my controller to be tested.  Here is where the concept of mocking comes into play.

There is a lot of internal plumbing that is setup by IIS during the process of processing an HTTP request.  Objects such as HttpContext, cookies, etc. are all wired up before control is passed to your application for further processing.  This makes it very difficult to implement unit tests – at least it used to.  With the new MVC framework, Microsoft has completely reworked the IIS stack to make it possible to setup the entire environment outside of the web server.  There are a number of ways to do this, but the approach I’ve settled on utilizes a project called Rhino Mocks.  I have a static class called MockControllerBuilder, which takes care of instantiating my controller with all the surrounding plumbing mocked up and in place.  So, for the feature I’m developing right now, my next step is to expand MockControllerBuilder to provide a method for creating my new controller.  I do this by adding a new method to the class:

The highlighted red code indicates that I don’t yet have a TransactionJsonController class, so I’ll create that next.

Notice that this controller (as all controllers following this pattern) has two constructors.  One is the default constructor (no arguments) used by the MVC framework to instantiate my controller during the processing of a live HTTP request.  The other constructor is used by the test framework, and it utilizes a pattern known as Dependency Injection to pass in an instance of my fake repository.

My last step to complete the setup is to use the mock controller builder to create an instance of my controller, like this:

The CreateTransactionJsonController method takes two arguments – an instance of the fake repository, and a profile (or null).  By passing in a profile, I am simulating which user is logged in as the controller processes the request.  If you look at the fake repository for the instance of the UserProfile with username sbradley@trustecx.com, you will see that this user has been assigned the “Admin” role, so this test will execute as though an Admin user is logged in.  By doing this, the unit tests can be constructed to execute under the authorization parameters of various user accounts.

With this done, the test setup is complete.  Now I move on to setting up expectations.

The Issue

As with many bugs, the behavior didn’t show up until the application was deployed – it worked fine in the development environment. My app uses Linq-to-SQL, and includes an IDE-generated DBML file to interface with my database. The app was connecting to my local database just fine. However, when the app was deployed, and all the changes to the connection string in the web.config file were updated, the connection to the database failed with the error “A network-related or instance-specific error occurred while establishing a connection to SQL Server”. What??

The Solution

After digging and googling, I discovered something about the IDE behavior when it comes to Linq-to-SQL and DBML generation. When the DBML file is first created, the IDE inserts an entry in the Settings.settings file, which contains the full connection string details. Since this connection string matches the settings in my web.config and the app.config for my local projects, everything works fine. The problem is masked by the fact that both the settings file entry and the config file entries are the same. So, to fix this requires first changing the settings on the DBML file to not use the connection string in the Settings.settings file.

After that, the constructor for the repository needs to be updated to use the configuration manager to pull in the connection string from the config file, like this:

Once this is done, the app will pull in the connection string from the config file, and no more error!

To begin, I open up the solution and locate the unit test project.  It should look like this:

Since I will be writing a json controller eventually, I will start by creating a new item in the JsonControllerTests folder, called TransactionJsonControllerTests.cs.  This class will hold all of my tests for transactions.  To start with, the test class is minimal, so it looks like this:

One of the basic tenants of Test Driven Design is that the test should always fail first.  Write the test, make it fail, make it pass, repeat.  This example is a little silly in its extreme, but it makes the point – this test will fail when it is run.  The reason for doing this is to avoid the subtle bugs that creep in when tests pass because the test is not written correctly.  It helps to avoid the error of false positives.

Now, when I run the test, I get:

I see that indeed, my test did fail.  Ordinarily, this process would have taken less than two minutes, and I am setup on a solid path with the knowledge that my code will be thoroughly tested in a repeatable manner.  My thought process has been very focused, and I’ve not wasted any time on ancillary issues that may or may not come up during the rest of the development of this feature.  The key is to focus on the simplest aspect of the feature, write the test, make it fail, make it pass.  Now I move on to initializing the test conditions.

Basic Test Driven Development

For this tutorial, I am going to implement the ajax controller that provides the summary of transactions by member for the current month.

From the preceding screenshot, Firebug tells me that the URL localhost/TransactionJson/Transactions does not exist.  So, you might expect we would start by implementing this URL.  But that would not by the TDD way!  No, instead, I will start with writing a test.