After lots of months of planning discussions and idea tennis; I am pleased and proud to announce my good friend Jonathan Rasmusson has come on board the Nothin But * Training banner. He comes armed with his own Agile Project Management training course that I am positive is going to take the market by storm.

People who know me are aware of the fact that I am very picky about the people that I choose to work and collaborate with. I need to ensure that the training delivered to people who engage jpboodhoo.com and the Nothin But * brand is of the highest quality, taught by active practitioners in the field. Having worked with Jonathan on projects in the past, I can personally attest to his level of excellence in the arena of Agile Project Management.

If there was ever a time that you though you needed to get an idea for what it truly means to run an agile project, March will be a good time to check out the beauty of Calgary whilst immersing yourself in what will definitely be an amazing week of agile deep diving!!

The course registration link can be found here. The description of the course is as follows:

Overview

As more companies introduce elements of agile delivery practices into their organizations, it is imperative that leaders be knowledgeable and informed on their effective application.

Whether you are new to agile, or just looking to improve, this intensive 4 day course is specifically designed to give you the hands on training required to successfully manage and deliver agile projects within your organization.

Core Concepts Overview

Agile Intro

• Agile in a nutshell
• Agile’s roots and history
• Where did agile come from?
• What makes agile different?
• How does agile compare with traditional forms of delivery?
• Principles behind the practices
• What are the principles that underpin the practices?

Agile Project Inception

• How to setup your project for success
• How to start your first agile project.
• 10 things to do before starting any project.
• How to make sure everyone is on the bus.

Agile Project Execution

• Fundamentals on agile project execution
• Role and responsibilities
• Team practices
• Iteration/Release Planning
• Building the first plan
• Story gathering
• Estimation/Prioritization
• Iteration mechanics
• Analysis/Development/Test
• Communication & Collaboration
• Tracking
• How and what to track?
• Big visible charts
• Effective status reports
• Continuous improvements through retrospectives

Agile Project Wrap-up

• Transitioning to support
• Documentation
• Agile myths

Course Pre-Requisites

• A positive attitude
• A willingness to share, learn and grow
• Ability to play games and have fun

About the teacher : Jonathan Rasmusson

As an active participant in the Agile community since 2000, Jonathan has extensive experience as a developer, architect, and project manager on the application and execution of Agile projects.

With experience introducing agile practices at Fortune 500’s (British Petroleum and Microsoft), to startups (Cambrian House), Jonathan is uniquely qualified to help those interested in learning how to successfully setup and execute agile projects.  As a former agile evangelist at ThoughtWorks, Jonathan travelled extensively helping companies introduce and apply agile delivery techniques to their unique situations.

Register Now – Introductory Offer

Because this is the first time this course is being offered, sign-up now for the one time low price of $1000 USD (regular price $2500).

This includes:

• all printed media
• lunches / coffee
• and 4 days of incredible learning and growth

Register now. Spot's are limited and this course will fill quickly at this one time low price.

Course Registration

• The course registration link can be found here

If you have any questions please don’t hesitate to contact me at jp@jpboodhoo.com.

I have received a number of good responses from people who have a couple of aesthetic issues with the BDD style naming that I am starting to use. Let me clarify, I have been using the natural sentence style test naming since Scott introduced me to it in earlier in the year. I have not used the context/specification style test naming on a project yet, though it is my intent to write each successive test from this point forward in that style and if I feel pain points I will let you know.

From my experience so far here are some tips that I think will resolve the issues that the people who are trying to use it will find:

Issue 1 – “I ended up really not liking those fixture names because I felt it was hard to find fixtures for specific classes, and navigate with Resharper Type navigation.  Was wondering what naming convention you came up with for fixtures?”

A: My recommendation for this is to create a single test class in your test project called $SystemUnderTest$Specs. Where SystemUnderTest corresponds to the name of the class that you will be testing. This is just a grouping construct for all of the “Contexts” that will be run against that fixture. Inside the “Specs” class, you will create classes for each of the different contexts. Here is an example of one that I just rewrote the tests for the ShoppingCart class is the nothinbutdotnetweb.app project using this new style and I personally have to say that it was an awesome experience. One of the things that I found was that I could copy the body of one fixture and change the name to reflect the new context and I could focus solely on the interactions and behaviour that is pertinent to that particular context. Take a look at the Report that is generated when run against the specs in the ShoppingCartSpecs class:

• When a product is added that is not already in the cart
• The cart item factory should be used to create a cart item for the product being added.
• When an item is added
• The item count should be incremented
• The item should be added to the underlying list
• When the same product is added again
• The item factory should not be leveraged
• The quantity of the item should be incremented
• When changing the quantity of a product in the cart
• The item should be updated with the new quantity
• When changing the quantity of a product causes the item to be empty
• The item should be removed from the cart
• When changing the quantity of a product that is not in the cart
• Nothing should happen
• When a product is removed from the cart
• The item representing the product should be removed
• The number of items in the cart should decrease
• When asked to remove a product that is not already in the cart
• Nothing should happen
• When the cart is emptied
• There should be no more items
• When asked for the quantity of a product
• The cart item representing the product should be asked for its quantity
• The result should be the quantity of the item for the product
• When asked to calculate the total cost
• Should be the sum of the total cost for all items

One of the things you will notice about the tests in these fixtures compared to the others in the rest of the project (so far) is the use of Setup to stress the context setup. I added a virtual method to the AutoMockingTest base called because, which calls out the action being invoked on the SUT.

This actually resulted is some tests that contained no body whatsoever, and the ones with assertions actually only needed one assertion.

This is a learning experience for me to, but so far, I am loving the expressiveness and focus this style of testing brings to the table.

By grouping all of the fixtures into the ShoppingCartSpecs class, you can solve the navigability issue.

The second issue I received was:

“Quick question ... while the idea is great, it doesn;t flow for me, as ReSharper keeps cutting in and completing my words for me - Intellisence is great, but in this context is is annoying as hell ...

How do you avoid this problem?”

A – This is actually a ReSharper setting that I have had turned off pretty much since I started using ReSharper:

• Go to ReSharper – Options
• Select the Intellisense item in the left nav bar
• Uncheck Letters and Digits in the Completion Behaviour pane on the right!!

That’s it. Now you can write you natural sentences without ReSharper getting in your way. Since I have been without this setting since ReSharpers inception, I have gotten quick at using ALT-SPACE/CTRL-ALT-SPACE a lot, this may take a bit of getting used to for the people who were use to the Letters and Digits autocompletion behaviour.

Again, as far as quickly navigating to the tests for a sut, you can just go CTRL-SHIFT-N and then start typing in the significant letters for the Spec class, in this case it would be:

CTRL-SHIFT-N -> SCS

Because all of the fixtures will be contained in the file but there will be no ShoppingCartSpecs type. I guess you could create one as a nesting construct, but that is what the file is for.

Again, let me stress that this Context/Specification style naming is a little new for me, and there is a possibility that the tests in the ShoppingCartSpecs that have no assertions could be a smell (I’ll get that verified by Scott in a little while), I already see the benefits from both the documentation perspective as well as the ability to truly only focus on one specific context at a time.

Develop With Passion.

After an awesome session pair programming with Scott the other day, I am going to start taking advantage of natural sentence style naming for not just my test method names, but the names of the test fixtures themselves.

The name of the fixture will now become the context for the tests inside of that fixture. It is actually surprising what level of detail this allows you to express yourself.

I had to change my test naming macro to support classes also. Here is the fix:

Imports System
Imports System.Windows.Forms
Imports EnvDTE
Imports EnvDTE80
Imports System.Diagnostics

Public Module CodeEditor

    Sub ReplaceSpacesInTestNameWithUnderscores()

        If DTE.ActiveDocument Is Nothing Then Return
        Dim wrCS As Boolean = DTE.Properties("TextEditor", "CSharp").Item("WordWrap").Value

        Try
            DTE.Properties("TextEditor", "CSharp").Item("WordWrap").Value = False
            Dim selection As TextSelection = CType(DTE.ActiveDocument.Selection(), EnvDTE.TextSelection)
            Dim index As Integer

            selection.SelectLine()
            If selection.Text = "" Then Return
            
            Dim methodIndex As Integer = selection.Text.IndexOf("public void ")
            Dim classIndex As Integer = selection.Text.IndexOf("public class ")

            index = CType(IIf(methodIndex >= 0, methodIndex, classIndex), Integer)

            Dim prefix As String = CType(IIf(methodIndex >= 0, "public void ", "public class "), String)
            prefix = selection.Text.Substring(0, index) + prefix
            Dim description As String = selection.Text.Replace(prefix, String.Empty).Trim
            selection.Text = prefix + description.Replace(" ", "_").Replace("'", "_") + vbCrLf
            selection.LineDown()
            selection.EndOfLine()
        Catch ex As Exception
            MsgBox(ex.Message)
        Finally
            DTE.Properties("TextEditor", "CSharp").Item("WordWrap").Value = wrCS
        End Try
    End Sub
End Module

Develop With Passion

Having received a bunch of emails in the past couple of weeks from people who have been asking me questions with regards to Passive View/Supervising controller patterns for web applications. I needed to let people know that for the last couple of months I have been developing web apps in a completely MVC style which eliminates the need for patterns like Passive View/ Supervising Controller.

For the people who are using the MVP pattern in their (web) applications I personally would now lean to the Supervising Controller style as it eliminates a lot of necessary chattiness between the view and the presenter. It also lends itself to much more simple unit tests.

Having gotten back into the Smart Client realm, I am once again reminded of the importance of patterns like Supervising Controller and presentation model as becoming essential to ensuring correct separation of responsibilities.

For my web applications, however, all I use now is a:

• Front Controller
• Commands
• View Templates (ASPX style!!)

Here is an example of what I mean, for the nothinbutdotnetstore.web.app project that is currently hosted on google code, here is the Command that processes getting a list of the main departments in the store for viewing:

using NothinButDotNetStore.Infrastructure;
using NothinButDotNetStore.Infrastructure.Container.Common;
using NothinButDotNetStore.Tasks;
using NothinButDotNetStore.Web.FrontController;

namespace NothinButDotNetStore.Web.DepartmentBrowser
{
    public class ViewMainDepartments : ICommand
    {
        private ICatalog catalog;
        private IRequestContext requestContext;
        private IViewEngine viewEngine;


        public ViewMainDepartments(IHttpContext context) : this(context,
                                                                DependencyResolver.GetImplementationOf<IRequestContextFactory>().CreateFrom(context),
                                                                DependencyResolver.GetImplementationOf<IViewEngine>(),
                                                                DependencyResolver.GetImplementationOf<ICatalog>())
        {
        }

        public ViewMainDepartments(IHttpContext context, IRequestContext requestContext, IViewEngine viewEngine, ICatalog catalog)
        {
            this.catalog = catalog;
            this.viewEngine = viewEngine;
            this.requestContext = requestContext;
        }

        public void Execute()
        {
            requestContext.AddToStateBag(ViewBagItem.Departments, catalog.GetMainDepartments());

            viewEngine.Display(Views.ViewDepartments);
        }
    }
}
 
Here is the complete ASPX (View Template) that gets rendered for that command executing:
 
 

<%@ MasterType VirtualPath="~/Store.master" %>
<%@ Page Language="C#" AutoEventWireup="true" 
    Inherits="System.Web.UI.Page"
 MasterPageFile="~/Store.master" %>
<%@ Import namespace="NothinButDotNetStore.Web.FrontController"%>
<%@ Import namespace="NothinButDotNetStore.Web"%>
<%@ Import namespace="NothinButDotNetStore.Infrastructure"%>
<%@ Import namespace="NothinButDotNetStore.DTO"%>

<asp:Content ID="content" runat="server" ContentPlaceHolderID="childContentPlaceHolder">
    <p class="ListHead">Select An Isle</p>
        
    <table>
        <% int rowIndex = 0; %>
        <% foreach (DepartmentDisplayItem dto in ViewBag.GetItem(ViewBagItem.Departments))
           {
        %>
                <tr class='<%=(rowIndex++ %2 ==0 ? "nonShadedRow" : "shadedRow" ) %>'>            
                    <td>
                        <a href='<%= Url.ToBeProcessedBy(CommandNames.ViewSubDepartments)
                                    .AddPayloadValue(PayloadKeys.DepartmentId,dto.Id).Build() %>'>
                            <%=dto.DepartmentName %>
                        </a>
                    </td>
                </tr>
        <%          
           }
        %>
        
    </table>
</asp:Content>

There is no code behind for this aspx page. The logic in the aspx file is there because it is rendering related logic. This aspx page does not talk to a service layer or domain objects or even a data access layer. It reaches into a ViewBag looking for information that it can render, and then it proceeds to do exactly what it should, render the information. What may not be immediately obvious is that this is a plain aspx file with no codebehind file. The page inherits from System.Web.UI.Page.

As far as testability of this style of development, here is a sample test for one behaviour of the ViewMainDepartments command:

        [RunInUnitTestContainer]
        [Test]
        public void Should_populate_the_context_with_the_departments_to_display()
        {
            ICommand sut = CreateSUT<ViewMainDepartments>();
            IEnumerable<DepartmentDisplayItem> results = CreateMock<IEnumerable<DepartmentDisplayItem>>();

            using (Mocks.Record())
            {
                Expect.Call(mockCatalog.GetMainDepartments()).Return(results);
                mockRequestContext.AddToStateBag(ViewBagItem.Departments, results);
            }

            using (Mocks.Playback())
            {
                sut.Execute();
            }
        }
 
 
 

In the next little while I am going to shed some more light on this approach to web application development. IMHO, the separation of concerns for web applications written in this style is much greater than when trying to stuff in a pattern that (again IMHO) did not fit well for the technology, and was leveraged for the sake of increased testability.

I finally set up a googlecode project to host source code for the various things I have been doing over the last year. The first major significant contribution is of course the code drop that I promised a week ago now!!

The application is the start of what I hope will evolve to be a great learning resource for lots of things related to .Net development. The application does not currently cover any of the “extra” topics that I did not have time to get covered in the course. This is perfect because as request come in from people (including past students) asking how to tackle a certain problem, I will use this application as the demonstration area where I can tackle the problem, and update the code base, and you will be able to update your local copy and carry on.

I am currently in the midst of a large Smart Client application that I am hoping to be able to harvest pieces of code out and do the exact same thing except for the smart client realm. I have much more experience developing in the smart client realm and that is where I feel most comfortable, so I am looking forward to be able to do another code drop (for a different application) in a couple of months.

I am going to write up another post about the Web Application as it is built very differently from traditional .Net based web applications. In following with the theme for my courses, there are currently no 3^rd party frameworks (other than log4net) that have come into play. My goal with this web app is to demonstrate to people how far we can push raw .Net. The goal being that expanding their knowledge of how to creatively leverage .Net, they will be better prepared to jump into frameworks that they may currently feel daunted by. As time goes by, I will swap pieces of the application out with components that people are asking to see meaningful samples on:

• NHibernate
• Castle
• Prototype
• JQuery
• ..*

As the app stands right now I see it as the beginning of what will shape up to be a pretty mean machine!!

I am going to post a screencast that will show people how to get started working with the web application. For people who are eager to get going right now, here are the quick and simple steps without a lot of explanation (that will come in the next post):

• Anonymously checkout the trunk from the google code repository using the following svn command line:
  svn checkout http://jpboodhoo.googlecode.com/svn/trunk/ jpboodhoo-read-only
  
• Navigate to the checkout folder
• Go into the build folder
• Copy local.properties.xml.template and paste it into the same directory, then rename the copied file to local.properties.xml
• Open up the local.properties.xml file with your favourite text editor.
• Modify any of the settings in the file that are different on your machine.
• Open up a command prompt and navigate to the build directory of the code.
• type: build load.data and hit enter.
• type: build test.all.woc
• type: build run
• The last task should fail (I haven’t automated everything yet)
• Create a virtual directory called nothinbutdotnetstore that points at the following location (this location is created after you attempt to run the build run task) : ${checkoutfolder)\build\deploy\web\app
• After successfully creating the virtual directory try the build run task again.
• If the web browser pops up pointed at a web page (for the app) you are in business. Feel free to click through the first set of pages that are implemented (only 3 pages are currently implemented).

As far as what I have planned to implement in the web app (that is currently not implemented):

• Build out a more extensive domain model that encompasses some more advanced scenarios of the application (especially around order processing).
• Unit Of Work for the service layer
• Implement a lightweight OR/M layer
• Integrate some UI frameworks like prototype
• Eliminate Master Pages completely and switch to a much more elegant template view pattern.
• Introduce a more robust container (as the current one is a simple dictionary wired up in a simple procedural fashion).
• Introduce the concepts of lifecycles for the items in the container. Right now, everything wired into the container is essentially a singleton.
• Introduce CSS based layout for the web pages (working with a designer on this one).
• Bring security concerns into play
• Demonstrate how to effectively manage sessions
• ……lots,lots,lots more!!!

Obviously I will be leaning on people checking out the code and playing around with it and submitting requests for things they would like to see.

There are a couple of things that you will immediately notice about the application:

• Clean front controller implementation with ASPX pages as the template views. There are no code behind pages in this web application. All web requests are handled by command objects that interact with the service layer, push the details into a “ViewBag” and then choose which view to render.
• Logical layers in the project are separated using simple folders and namespaces (not full blown projects)
• Build automation is its own project in the solution (props to Jay Flowers for this inspiration)
• The current container implements (CustomDependencyContainer) is very simple and is handled by a big procedural application startup task.
• Compile time support for the database layer. A couple of classes ago I introduced the concept of a generic TableColumn<T> type. In England after introducing this concept Scott Cowan leveraged his knowledge of MyGeneration to automatically generate strongly typed table definitions that we could leverage to do mapping (trust me when I say, this is nothing like datasets). Until moving into OR/M concepts deeper this gives a good place to start as the generation of the TableDefinitions is linked to whenever the SQL files change, so you will get compile errors if column types are now mismatched etc…

There are lots of other things I could talk about, but this code really is the start of what I see being a long running conversation between myself and other people wanting to learn. In all honesty for all of the emails I have not paid attention to this year, hosting code through google will allow me to answer peoples questions in a much more meaningful way as I can point them at this site to see the implementation of the code they had questions about.

I am going to be placing all of the code for presentations that I have done for the last year as well as continue to update it with the source code that comes out of new courses that will be coming out in the new year, and the DNRTv episodes.

Once again, the application is currently in its infancy, but as people start sending in the requests I now will have a venue and example to add upon to answer questions in a much more timely fashion!!!

Develop With Passion!!!

I had to laugh when I read “TDD Ain’t No Snowboarding from Alessandro Burrato. It is a direct counter to my TDD is Like Snowboarding post!!

His experience of TDD is very different than the experience I documented based off of my experience introducing it to clients. And I feel that his recollection of the experience is definitely one that I would like to see more in the clients that I engage and the people that I talk to

He makes one very good point that I can’t stress enough to people who spend their days reading blogs about the great stuff that people are doing, to quote him:

“If, and only if, you stop seeking pre-cooked answers from those who already tried it and start friggin’ DOING something.”

At one point or another, practical knowledge of a topic far outweighs any theories you may have built up in your head!!

Nice post Alessandro.

A lot of people will probably say it is about time!! I am taking the source code that just got driven out from this last week of Nothin But .Net and I am going to make it publicly available from my blog. I am hoping to release it by the end of the week. The reason that I can’t release it yet, is that there are lots of concepts that I wanted to cover in class that I did not have time too, so I am going to spend a bit of time fleshing out the code base to include all of the concepts that were missed (by student request)

Keep in mind that Nothin But .Net is a course about fundamental software development practices with a bit of a .Net slant. Here are some of the things you will be able to see in the code base:

• How Test Driven Development was used to drive out the functionality of screens in the application in a top down fashion
• The benefit of using Data Transfer objects not as a marshaling tool, but as a tool to let the needs of the UI not influence unecessary changes to the domain model
• The benefits of leveraging layered architecture
• Why you don’t need lots of projects in your enterprise solutions if you are using an automated build (take  a look at the following screenshot to get an idea for the solution structure
• Clean Front Controller implementation so that you can eliminate the need for messy Passive View/Supervising Controller implementations just for testability of the web form world
• Good practices around mixing both interaction and state based testing
• Test partitioning (integration, unit, acceptance)
• My current project build structure
• How to avoid the overspecification problem with interaction based testing
• Rhino Mocks and leveraging the automocking container (thanks James for getting me hooked on this thing)
• Fluent Interfaces
• Build Automation
• NAnt compilation as an effective tool for pruning dead code that studio does not show
• NAnt as a build tool
• NAnt as your compiler and test runner
• Build file partitioning
• Use of filesets
• Machine agnostic build files through use of local property files
• Unit Testing
• Focusing on one thing at a time
• Incremental testing
• Breaking reliance on setup methods
• MBUnit
• Decorators used effectively
• Design Patterns
• Visitor
• Factory
• Data Transfer Object
• Adapter
• Proxy
• Mapper
• Unit Of Work (lots of people have been bugging me about this for a while)
• Lazy Loading
• IOC
• Gateway (and Static Gateway)
• Service Layer
• Identity Map
• Data Mapper
• Database Gateway
• Money
• Null Object
• Strategy
• Composite
• Command
• Template View
• Query Object
• Specification
• Domain Model
• Separated Interface
• Design Principles
• Single Responsibility
• Open Closed principle
• Dependency Inversion Principle
• Hollywood principle
• Tell Don’t Ask

I am sure I am missing lots in the description above, but you get the general idea. The important thing to note, is that all of the code (except for the changes I am making this week) was driven out through the course of the one week bootcamp!!

I am going to spend a couple of days ensuring that it contains as much code as possible for an initial drop, with full end to end functionality in place.

Going forward, this code will serve as a good place for me to be able to demonstrate in a public arena, concepts that people email me and ask me questions about. This way, I won’t have to spend as much time blogging, people can send me a question about something they are having problems with, I can implement the solution in the codebase and they can see how I attacked the problem from a test first perspective.

I envision this as being a very organic application. I am going to use it as a public tool to share whatever knowledge I have with as many people as possible.

When I post the code I will make sure I post a little about the application and why I feel that it will serve as a good tool to both teach and practice.

I just received the following email that I thought I would share and answer publicly:

“I’m not using this methodology (TDD) because my principal question remains unanswered. I know that with TDD you should release less bugs, but what about the time needed to develop with that methodology ?

I would like to know if the time to develop an enterprise solution is faster, equal, or longer with TDD.

I hope you will be able to answer me because i’m very intrigued and interested by TDD and DDD.”

The first and most important point that I would like to draw attention to  is the misconception that TDD is a tool to ensure that you should release less bugs. Although one side effect of TDD is the fact that you may well end up with a smaller bug count that is not the driving factor behind the adoption and practice of TDD. The driving factor behind TDD is that of driving out the design of components in your system one test at a time.

With respects to the question:

“I would like to know if the time to develop an enterprise solution is faster, equal, or longer with TDD.”

When you first make a decision to head out onto the ski hill and take a shot at snowboarding you head out with a dream in your head of being able to carve it up within minutes and do tricks that would make SSX Tricky look lame. The reality of the situation quickly kicks in once you have fell for your first couple of times and you realize that it is going to take a bit of time before you become proficient enough just to traverse the hill without any glitz and glamour. If you are wise, you will take the time to get instruction from a qualified teacher, who can help you establish good footing and technique from day 1. Building upon this base of solid instruction will ensure that you able to grow as a snowboarder effectively over the next couple of months, and potentially avoid picking up any bad habits you may have formed had you tried to pick up the sport yourself without any instruction.

Like snowboarding (or any new skill you wish to acquire), in the beginning a lot of learning is going to be taking place. For the majority of people who venture into TDD waters, they realize that there are potential big holes in their skillset that may cause them pain in this new world. Assuming that those holes are not there, you will still have to deal with the fact that for the first little while you will be training your brain to tackle and solve programming problems in a way that it is not accustomed to. This is actually one of the biggest hurdles people have to jump when getting into TDD. The development of a new style of coding that forces you to think about a small win and code the API as if it is already there. A good way to start into TDD is to start with state based testing. Once you have got a good handle on state based testing you may mix it up with interaction based testing also.

The fact of the matter is, when you start TDD you may very well end up finding yourself moving ahead at a slower pace than normal, this is predominantly because you will be working out of a comfort zone that does not yet feel natural. When you experience your AHA moment with TDD, it will be shortly after that when you realize that writing the test has now become a natural extension of how you work, you won’t need to account for the fact that you are using TDD to build a project, as it will be melded into the way you function as a developer.

Having witnessed two teams (one agile, one non agile) with developers of the same caliber being asked to deliver functionality on a project. The team that practiced TDD was able to meet the needs and changing requirements in a way that completely surpassed the team that was coding without TDD. I have seen it work on my own projects countless times, projects ranging is size from the small to the large enterprise level. I personally would not be trying to teach people the benefits of TDD if I did not feel it was a justifiable learning to undertake. Speaking for myself, it has completely transformed the way I look at solving problems in the programming realm.

Much like many developers have acquired traits and behaviours with respects to their coding style and how they solve problems, TDD becomes another “natural” trait that becomes part of what you do to solve problems. The first thing you will do when faced with a problem is write a failing test to capture the requirement that you want met.

Ultimately, people have to make a decision to take a walk down TDD avenue and stick with it long enough for it to become something that feels natural. If you don’t give it a good shot, you could walk away not realizing the benefits that TDD can bring to your development arsenal.

For those of you who are looking at TDD as a serious option but have not yet picked it up, this may be a good season to hit the hill!!

That last part in the title is to indicate that for me, this is something that has changed several times over the past year with a change happening even within the last month.

Let me stress the fact that I am a big automated build junkie, and am not really even a fan of compiling from within studio. To that end I do the majority of my work using studio + ReSharper as the editor, and NAnt (currently) as the compile/test tool coupled with FinalBuilder as my deployment tool.

Here is a snapshot of a root directory of one of my current projects:

Let’s break each of these items down so that there is a bit of explanation behind each one. Don’t worry about the .svn folder or the folders with underscores in front of them.

The config dir

This directory contains all of the files related to the configuration of the application. Things that I typically put in this directory are:

• app.config file template (if you are not sure of the concept of file templates check out my NAnt starter series).
• NHibernate mapping files (typically placed in a folder called mapping)
• Log4Net config file template
• Boo file template to configure Windsor

The docs dir

This directory should be fairly self explanatory, as it contains documentation artifacts related to the project. These can be things like stories, diagrams etc.

The lib dir

This directory contains all of the third party libraries that will need to be deployed to the client/server machine. Keep in mind that 3rd party libraries could also be app specific versions of in house libraries that you share between projects.

The src dir

This directory contains all of the code related artifacts that belong to the project. This application usually consists of the following 2 root directories:

• app – Contains all of the code that will be compilable units that get deployed to production.

• test – Contains all of the code that is related to testing the code that will get deployed.

I often break the test directory down into different subdirectories to clearly identify the types of tests that are contained:

• unit
• integration
• ui

The src directory is organized in this structure so that I can quickly choose to ignore/include files that I want when I am compiling for either test or deployment.

The tools dir

This directory contains all of the supporting third party libraries that are there to serve the purposes of build automation, testing etc. Libraries that you might expect to find in here are:

• NAnt
• MBUnit/NUnit
• NCover
• NCoverExplorer
• RhinoMocks

These libraries are essential during the build process, but they do not need to be present on the deployment machine as they are there to support the needs of automating and testing the application.

The local.properties.xml file

This file is there to account for the differences in individual machine configurations without cluttering the build file with knowledge of each specific developers machine in a team environment. Machine specific settings are kept in this file that each developer maintains their own copy of, and the settings in the file get leveraged during the build process to carry out the build automation tasks on each developers machine.

You will also note, that in the above diagram, I place my solution file right at the root so that it is quickly accessible and can be opened right from the checkout unit.

As you can imagine this physical folder structure does not correlate to what you would see in studio, as unfortunately, studio comes up with its own way to view your world.

In a latter post I’ll talk about how I have abandoned the notion of multiple projects inside of studio, in place of trusting developers to follow correct layer separation. This can be done, because once you stop using Studio as your build engine, a world of possibilities open up to how you go about laying out the physical code in your code base.

Why

The purpose for having this structure that I have outlined above is to have a completely atomic unit for your project. The goal being that someone new to the team, with a fresh install of the .Net framework (not even studio), should be able to check out the above project, make the appropriate machine specific changes to the local.properties.xml file, and run build.bat to compile and test the application. One of the directories that you don’t see in the image above, that is usually present on other apps that I write is the sql directory. As you can imagine, this directory contains all of the sql artifacts related to the project. Again, if a new developer checks out for the first time and tries to build/test, if there are databases to be created, they will be created, and then the code will compile and test.

Again, once you introduce the concept of build automation whether it be with NAnt, Rake etc, it opens the door and your mind to different possibilities with regards to how you go about laying out your project. No longer is your deployment model constrained to how you build your x number of projects in studio. You could have one physical project with 15 different folders that convey different namespaces/layers of the application (which you would originally have been using separate projects for) and you could choose in your build script to compile folders 1 – 5 into one assembly 6 -8 into another assembly etc. It is completely up to you.

There are so many other things that you can do when you start using this type of structure.

A while ago I got asked the following question:

I've been wondering something about
OOD that perhaps many developers think about, and that is the
relationship between the amount of time used for design (eg. drawing
UML) and actual coding.
 
What's your take on this? Do you like to design everything from the
high-level till the ground-level with UML? What UML diagrams you find
most usefull? Or do you think that using pure TDD makes UML somewhat
obsolete?

Since I got introduced to agile methods, I was also introduced very early to the concept of “code” as a design tool. To be more specific, this is the concept that everyone has come to know formally as Test Driven Development. When practicing TDD/BDD the goal is to write the test before the code that you are wanting to create actually exists. Don’t forget what we are doing here, we are writing “code” for “code” that does not yet exist. This gives us a completely blank slate to work with. This allows us to code the object with the exact “behaviors” that we would want it to exhibit and the API through which we interact with it. After you have been doing TDD for a while the “explicit thought” of “I should write a test” becomes a habit, so you write the test first without even thinking about it. This is great. When you have been doing TDD for a while.

The problem lies for the people who are fresh into TDD and they are still in that uncomfortable period where it does not yet feel natural to write the test first. As much as TDD is about design it is also about “moving ahead”. When you find yourself staring at a screen and lost for which direction to drive out a test the answer is simple “Get Up In Front Of A WhiteBoard and Draw!!!” (I am making the assumption here that you have already tried talking with your team and you are all collectively at a loss for where to begin). If you are feeling stuck and unable to move ahead one of the following diagrams :

• UML Class Diagram
• UML Sequence Diagram

may help to generate some ideas in your head that can serve as a starting point for helping you to drive out the test. Of all of the UML diagrams, the only ones I find myself using anymore are:

• UML Class Diagram
• UML Sequence Diagram
• UML State Diagram

Even on teams of experienced agile practitioners, it can often be beneficial to whiteboard an high level idea that you are having to quickly share information with the team and solicit feedback. These should be quick sanity check sessions where you are just brainstorming. It is not a 2 hour session where you are drawing out a complicated class/sequence diagram that will almost definitely not correlate to the resulting code that is produced. 

One of the most effective tools that a developer has in their arsenal to convey design ideas quickly (aside from unit tests) is a whiteboard and marker. So even though you may currently feel stuck with respects to which direction to take test; the act of getting up and trying to draw down a quick UML sketch can get the creative juices flowing and provide you with the ammo and direction with which to get back to the computer and start writing the test. Which is ultimately the design exercise you want to move to, as it is a “specification” that is able to adapt to the code that it is targeting (unlike a static UML diagram).

People starting out in TDD get very uncomfortable when they are often faced with the realization that the design skills they thought they had are actually not really that proficient. TDD brings this to the forefront because design is something that is being done constantly. Most developers that I know who are familiar with UML are able get in front of a whiteboard and come up with a quick sketch of a proposed object model they are thinking about. Put the majority of those developers in front of studio with an test fixture and they often flounder.

It is time that people started developing a different set of design skills. The skill of designing an application by “coding in reverse”. One of the best ways I try to describe TDD when I am pairing with someone is to “code it like it’s there and it has the exact API that you want to use”. Once people can take that phrase and literally apply it to a test they are writing for an object; they have crossed , IMHO , the largest learning gap on the road to effective TDD.

Do I think that design is dead? Absolutely not. TDD is first and foremost about design, not testing. It is a practice that requires discipline on the part of all the members of a development team. One of the startling revelations that people who are skeptical about TDD encounter when introduced into a team practicing it, is that the emphasis on solid design is actually much higher than other teams they have been a part of. Why? Because design is something that is happening almost every minute of every iteration. Developers working on stories are driving out the design of components one test at a time. They are driving out the communication between disparate layers in the system one test at a time. All of these “design” artifacts brought together with the accompanying implementation code, over the course of (x) iterations result in a piece of software that has been actively designed and developed over the entire lifecycle.

At the end of the day, I no longer see any value in BDUF. Let me stress this point, “this does not mean you turn a blind eye to changes that are coming in future iteration that may (most likely will) require change”. More importantly you build the system with tests as a design tool that enable you to keep your objects following:

• Single Responsibility Principle
• HollyWood Principle
• Dependency Inversion principle
• …….

This will ensure that when change comes (and it will) the effort required to  accomodate the change will not be a negative one. And will you be able to drive out the “design” and implementation of the change by following a set of repeatable practices that eventually will become second nature for you, if you stick with it.

This year has been an awesome year for allowing me to venture into the training arena. Although I am not a full time trainer (nor do I ever intend to be), I have greatly enjoyed taking a week out of my schedule once a month this year to deliver top tier Agile development training to students all over the US and Canada. For the remainder of the year I will be blessed with the ability to take the course offerings globally with my first course in England scheduled for September.

My focus this year has been on delivering – Nothin But .Net. An intense 5 day course that stretches people to think outside the box of how they typically program and delve into realms they have potentially not event thought about yet:

• Behavior Driven Development
• Applied Object Oriented Programming
• Incremental Design
• ……

I have greatly enjoyed delivering this course, but feel that it is time to throw some other course options into the fray. With that in mind, here are “some” of the courses that people will be able to request (on demand) for the 2008 calendar year:

• Nothin But Agile Project Management***
• Nothin But Virtual Wizardry***
• Nothin But Build Automation
• Nothin But An Introduction To Unit Testing
• Nothin But Test Driven Development
• Nothin But Domain Driven Design
• Nothin But Windows Presentation Foundation
• Nothin But Windows Communication Foundation
• Nothin But De-mystifying Design Patterns
• Nothin But Developing With Open Source Frameworks (NHibernate,Monorail,Windsor ….)

It should be noted that not all of these courses are 5 day bootcamps.

This is just a small sample of the offerings, and if your company is in need of training that is focused around a particular application that you are going to be (or are currently) building, all of the courses are completely dynamic and able to adapt very quickly to the needs of the students. I am about a week away from finishing my full blown web site where information on each of the courses will be explained in detail, and where you will also be able to request course offerings that you would like to see.

I am going to be collaborating with people over the next year to offer up a wide group of trainers who all exhibit the values and skills that I would expect of someone able to teach a Nothin But * course. Know that when you engage in one of these courses that your minds will be pushed to the limit for the entire duration of the course.

Being first and foremost a developer, I am still going to be only committed to teaching a course a month so that I can continue to “sharpen the sword” during the remaining weeks of the month. Leveraging collaborators will allow more people to get exposure to what I feel is pivotal training that can completely change your development career, it will also allow more courses to be offered over the course of the year than what I could offer on my own.

Spread the word, Nothin But * is coming your way!!

***I am fairly excited about these courses as there is a huge need for some de-mystifying around these areas.

That’s right folks. Nothin But .Net is coming to New York.

That’s right folks. Nothin But .Net is coming to England. This is especially sentimental for me as I was born and raised in England, and I have been waiting for an opportunity to go back and show my family the wonders of England.

This is a hot topic for me right now, as I talk with lots of people who are working through trying to make their teams more “Agile”. That word is a little overloaded and overused lately, so I am going to focus on how you can make your team more Extreme through use of practices and strategies that live in the world of the development team.

I am going to point everyone to James Carrs great post today about A Tale of Two Teams. It is a great post that helps me start of by making a big bold statement (reiterating what James said).

• Stop blaming other people for your inability to introduce practices and strategies that will make your team more effective.

As a consultant, I get the great joy of being “that guy”. The one who comes in to shake things up and challenge peoples assumptions about the way they build software and the software development process in general. Having a deep love for the practices associated with Extreme programming, I have crafted a set of strategies that I feel have helped infect every team/developer I have interacted with on the benefits of this “new” style of development. I want to share these strategies in the hope that they will inspire other developers who are in positions of influence (that is all of us) to encourage their development team to strive for something better.

Develop With Passion

This title is not a joke. My companies tagline is “Develop With Passion”. This is a crucial, but often overlooked element of introducing a team to a set of new practices. Whether people share the same values or not, people respect people who stand up with conviction for their beliefs. If you love what you do, other people will notice and (most) will want to share that passion you have for your work. If I come in completely fired up about the benefits of agile, yet am lukewarm in my delivery, the message will get lost.

Invest In Building Solid Team Relationships

Before you can hope to reach people at a technical level, and try to encourage them to improve their development practices, they have to know you are authentic. This is especially important for consultants, who are often viewed as the ninja paratroopers of the software development world. We swoop in, do a bunch of “magic”, then we leave!! This view has to be dispelled as quickly as possible. If a team that I engage does not believe that I truly care about them on a personal and professional level, they are not going to be able to listen to ideas that I bring to the table. My first couple of weeks on a new contract are spent building a level of trust between myself and the other developers that I am going to be working with. What does this investment look like:

• Lunches/Coffee breaks getting to know developers outside of the workspace
• Pair Programming Sessions where I can get an idea for each individuals skill level, providing me information I can use to focus future mentoring sessions
• Encouraging open communication within the workspace, which helps identify each developers comfort levels, boundaries etc.

Focus On Small Victories

After that first couple of weeks of building relationships, I should have a great idea of how much work needs to be done to get the developers thinking and practicing in a more agile fashion. For the majority of teams out in the wild, the practices that are second nature to most agile developers are almost completely alien. There is a limit to how much an individual can assimilate at one time. This means that if I come in and throw TDD,BDD, DDD, Interface Based Programming, Automated Builds, Continuous Integration etc.. at them all at once, it will be too much information. Based on the level of the team I have to focus on individuals and practices in a piecemeal fashion. Think of running it like you own mini agile project, with the end result being having your development team completely immersed in an agile environment. My set of small wins is usually introduced incrementally using the following steps:

1. Introduce the concept of an automated deployment script. If nothing else, to decrease the amount of manual time that is probably being spent on deploying applications that are going out to production. Some good tools for this are NAnt, MSBuild, or (my fave for deployments) FinalBuilder. The amount of individual time saved on decreasing the amount of human intervention required for deployment will allow your development team to focus on other tasks to ramp themselves up.
2. Start leveraging an automated build script to compile your application. This will inevitably lead to some codebase structure refactoring that will make it more malleable to an automated build script.
3. Introduce the concepts and practices of automated unit testing using an framework such as MBUnit.
4. Bring a continuous integration server into the mix. My current fave for this is CruiseControl .Net.
5. With the foundations in place, switch into a mode of pair programming with the client developers.

Once in a place where I can pair with developers that is where I choose to introduce the following concepts:

1. The benefits of trying to achieve mouseless computing
2. Real Object Oriented Programming
3. Interface based programming
4. Test Driven Development
5. Domain Driven Design
6. Object Relational mapping and all the other great tools that exist out there to facilitate rapid,testable development.

As you can imagine. It takes a bit of time to have this knowledge flow and be completely understood by each developer on a team. When it happens, amazing things start happening. Other teams start to notice, management starts to notice. Teams will be coming to your team asking you the secret to your success. And then the cycle starts again.

This is a way that teams, independent of management can start to achieve some gains associated with becoming more agile. I might be a little bit cavalier about my approach to team engagement/improvement, but I have always tried to follow this simple principle:

• It is easier to ask for forgiveness than permission.

More people need to start taking chances. Every single developer on a team , regardless of years of experience or title, is in a position to initiate change. Do you see room for improvement, introduce it. Be the catalyst for change that inspires other people. Don’t hide behind excuses that shield the fact that, more often than not, the problem lies with developers who are content to whine and do nothing, vs doing something and “maybe” receiving some heat.

Wanna be more extreme? Do what it takes to make it happen. It’s that simple.

I just had an awesome comment made on my unit testing post by Tom Opgenorth. It was so good that I though it deserves a post in its own right!! Here it is:

In trying to explain the "why" of TDD, I like the example of paying cash vs borrowing money.

Using TDD is paying cash.  You shell out the time (money) now, and all is good.  Your account is clear.

Without TDD it is like borrowing money to buy something.  You get what you want but there will come a time when you have to settle your debt, usually with interest.  

From a code perspective, this interest is usurious:  wasted time spent digging through a debugger, hoping that a breakpoint was set a the right place in code so you can see the error happen.

Awesome!! Thanks Tom.

In reference to the article on unit testing, here is an interesting excerpt from the following article written by one of my former colleagues Paul Julius:

“ The reason I was there was simple. Earlier that year, those same IT managers had performed a series of calculations to estimate how much it cost the department each time a bug made its way out of development, into SIT, into User Acceptance Testing, or all the way into production. For this IT shop, one bug into SIT cost them $12,605 (and you can imagine how much a bug into production would cost.) So, I did some quick math. The burn rate for the developer who introduced the bug was $70 per hour. Since the developer had already fixed the bug and committed the change, I deducted the $70 from the total and ended up with $12,535. Now, it cost them $70 (or less) to fix that one bug, instead of $12,605.”

So I’ll ask you again. Would you rather spend $12000 to fix a bug or $70?

The amount of times I am asked this question is fairly astounding. It seems that lots of people are struggling with getting their management (at this level I will talk about the Project Management level) to believe in the value of automated unit testing.

I am not even talking about Test/Behavior Driven Development, I am talking about simple state based unit testing. There seems to be a great misconception floating around out there that the act of unit testing is going to negatively impact individual/team velocity. Let me ask all of the developers out there another question. How can I convince a developer that refactoring is a good practice? This seems like a ridiculous question, but it actually points to the same principle. The reason that most developers will laugh at the statement about refactoring is that most good developers naturally learn to evolve their basic refactoring skills even with the absence of fancy design patterns etc. Going through a series of steps such as:

• This method is too long… I’ll break it up
• This class is too big…. I’ll separate responsibilities
• This behavior does not belong on this object…. I’ll move it
• This functionality does not belong in this layer of the application…. I’ll move it

That is a dramatic simplification of refactoring. Nonetheless, a good developer who has not been exposed to a refactoring catalog will inherently develop a habit of “natural” refactoring, for nothing less than to keep the quality of the code at a certain level.

One more question. When you are sitting there making estimates on how long a particular unit of work will take, do you estimate in time for how long it will take you to refactor code that you are writing? Ridiculous, if we are talking about a developer who has developed a natural habit of refactoring, it is just that “A Natural Habit”. This developer no longer needs to think about factoring in time for refactoring, because it has been factored into their very core as a development practice.

In my opinion, unit testing is the exact same problem. Not enough developers have developed a natural habit of unit testing their codebases. Content to jump into debuggers at the first sign of an issue, most developers spend an order of magnitude time greater manual fixing and verifying their codebases, when they could bit the bullet, write some automated tests, and have a computer do as much grunt work for them as possible.

Here is a question I would like to throw at developers (and management alike). Where do you want to spend the time? Would you prefer to spend the time flying through delivering untested features that are potentially going to come back with bug items that need to be manually debugged and fixed piecemeal. Or, write unit tests around as much code as you can, so that in the event a bug comes in you can:

• Write a failing unit test that captures the bug
• Update the code to make the failing unit test pass
• Keep the test in place to serve as a way to prevent the bug from reintroducing itself

Developers and managers alike are kidding themselves if they think that they are going to save themselves time by not having some form of automated testing in place. A very simple way to convince people of the value of unit testing is to record actual metrics that document the amount of time it takes to fix a bug in a system that has a suite of automated unit tests in place vs. a system that has no automated unit tests in place. Once you can convert that figure to a dollar amount in developer time wasted on bug fixing; it becomes very apparent to developers and management that there is an actual real cost saving that can be realized.

Above and beyond convincing management is the fact that, at a developer level, it is time for more developers to form some new natural habits in their development process. I am a personal fan of test driven development because while you are simultaneously flushing out the design for your system, you are left with a safety net of tests.

If you are not practicing TDD, you need to get yourself into a habit of at least unit testing critical objects/behaviors in your system. For projects that are well underway/deployed and have no unit tests in place, it is unrealistic to revisit them and retrofit the entire codebase with unit tests. A better strategy for these projects is to identify pain points in the application (areas with the highest level of bug activity/ areas with the most volatility) and get some unit tests around these “points of high visibility”. Going forward you can encourage developers to get unit tests around new methods/classes etc, and start to integrate some new habits into your developers.

I’ve been to a lot of conferences. Last week I got the opportunity to both speak and attend DevTeach 2007, in Montreal. I spoke on both refactoring and applying patterns of enterprise application architecture.

Along with presenting, I got to attend and watch awesome content presented by other speakers in the Agile track of the conference. I have to applaud JR and Scott for implementing the addition of an agile track to the conference. Every single one of the sessions was packed, an indication that the topics that were presented are obviously relevant and meaningful to lots of the people attending.

As cool as some of the presentations were, it was the networking that made this event absolutely stellar. Getting to hang out with Roy, Oren, Jeremy, Scott, Udi, Wendy, Oksana, Rod, Donald, Dave, Adam, Greg, Matthew and a whole host of others!! The conversation, arguments, debates, and just mindless chatter was the most fun I have had at a conference, ever!!

There was one evening in particular where the general concensus was that we had all been hit by a bus and were lounging in what must have been programmer heaven (complete with Carl Franklin and company in the background providing the ambient music)!!

Seeing as how the links to the presentation material are not currently working here is the rar file (download WinRar to extract) that contains the material for both of the presentations. I did not get a chance to finish getting through either presentation in both of the sessions, so the code you see is where I left off. I am hoping to screencast both presentations in their entirety so that people can see the end goal for both sessions.

Looking forward to DevTeach Vancouver…that right, its coming!!

This was published a while ago, but it is an awesome read. Made me laugh, and I just read it for the first time last week!!

Gives people some good things to watch out for when they are getting into/heavily into TDD.

One of my readers asked me a question that I thought I would share the answer to publicly. I have omitted his name to maintain his privacy:

Question:

I have been reading your blog for quite sometime now and had a quick question on TDD. I saw your screencasts and saw that you develop your tests first and then your actual classes. I use CodeSmith to generate most of my code although I tweak it to not be modeled exactly around my tables. Given this how do I make the jump to TDD? Using the method you showed, wouldn't it take a very long time to finish the project as you are hand coding each class one by one. I basically hand coded one module (from ASPX to all the way upto the backend) and then designed my CodeSmith templates around it.

I am not sure where he finds the time, what with home schooling 2 kids, consulting and speaking, but James Kovacs has managed to write a plugin to allow running VSTS unit tests from within ReSharper. If you happen to be one of those people who has to use the VSTS unit test, and you also have the joy of using ReSharper, head over and download it and give him some feedback!

One of the questions that came up a lot during my last developer bootcamp was : "JP, this is a lot of stuff to take in, what is a path you recommend for us to start implementing these techniques over the next little while?"

My answer to this question is twofold. The first and hardest answer to swallow is that you need to "Be Prepared To Unlearn". In my opinion, it is a lot harder for people to unlearn bad practices and ideas, as opposed to picking up potentially good and useful new ideas. The biggest unlearning comes from the fact that most developers truly believe that they are taking advantage of OO programming, when in reality the majority of their code is just procedural code utilizing objects. The shift that has supposedly happened has not truly been realized by lots of developers (this is not just applicable to the .Net world either).

Once people realize that they have not really been utilizing OO and its accompanying set of principles and practices, they want to know how they can start leveraging TDD, mock objects, ORM etc. Again, too much too soon is not necessarily a good thing. The other problem that people encounter is that once exposed to these new principles, devs want to rush back and start applying them to their existing (often bloated untested, fragile) systems. In reality, it is impractical to learn these new techniques and go back and tear the application apart (especially if it is working for the most part). The following list outlines a strategy that I suggest for blending new techniques, patterns, practices , and tools into your development environment (current project):

1. If you're not using source code control, stop reading this right now and go and get your code into an SCC, Subversion is a great free source code repository server.
2. Get a continuous build environment configured using a combination of either NAnt/MSBuild/FinalBuilder and CruiseControl .Net.
3. Set up automated scripts that can compile, and deploy your project (this will save countless time over the course of a month)
4. If you are in the camp that realizes that you are not truly sure what real OOP looks like, spend a bit of time reading up on some good material that will help you get an idea of what OOP is all about, some of my personal recommendations are:
   • Applying UML and Patterns
   • Head First Design Patterns
5. Identify hot spots in your application that cause you headache (lots of bug tickets), and make a strong effort to get some automated unit testing around those areas. Utilize frameworks like MbUnit or NUnit to accomplish this.
6. If step 5 is proving problematic because of a highly coupled system. You may need to start teasting apart dependencies and refactoring for a bit more testability. Again, only focus on the hotspots. If you are unsure about how to proceed, pick up the awesome book Working Effectively With Legacy Code which will introduce you to a host of techniques for getting yourself out of tangled messes in your application.
7. Get into the habit of unit testing new code that you write. This is not test driven development, but it will get you in the habit of ensuring that to the best of your knowledge, new functionality you are working on has a safety net of testing around it. This will serve many purposes down the road, especially if refactoring needs to take place.
8. Get some design patterns knowledge. It will allow you to speak a lot more concisely with your team members, and well as help you think about way to build more cohesive objects. If you are starting down the patterns path, beware of patternitis. In all honesty, when you are learning, you will rush to try and find a way to apply design patterns, with experiece you will realize that although you could use a pattern in a certain scenario, another solution could be simpler.
9. Start introducing the concept of interface based programming into your applications. By coding to abstractions, you will allow for systems that are far more loosely coupled as well as extremely testable.
10. By this point you should be comfortable with the concepts of unit testing and interface based programming, and all of the new development you have done, sticks out like a bright light surrounded by the darkness that is your old code. Now is the time to start getting into the habit of doing test driven development.
11. Getting into TDD is a bigger shift than the jump you will have already made to object oriented programming. The best piece of advice I can give is to stick with it. Code your tests imagining that the pieces you want to exists are already there and you can use them as you would want to, simply and easily. The nice thing about TDD is that you are designing your object from the perspective of a consumer of that object, this inherently will constrain you to keep the design as simple as possible. It is definitely beneficial if you are able to pair with someone who can help you down the TDD path (heck bring me in for a week or 2!!).
12. So you are now comforable with traditional test driven development, it is now time to add a new tool to your TDD arsenal, a mock object framework. By utilizing mock objects, you will be able to focus on writing tests for only one class at a time, while simulating any dependencies the class you are testing may have. My current favourite mock object framework is Rhino Mocks. By the time you introduce a mock object framework, you should already be comfortable with interface based programming, which will allow you to start integrating it into your tests very quickly.
13. Start playing around with some more OSS software, leverage dependency injection to acheive truly decoupled components, downlod and look at the source for existing open source projects.
14. This is the last and most important point:
    • Become a student of your profession - this is so important, most of the people who embark down this style of development do so because they have a passion to want to deliver applications that both please the user, as well as please other developers who maintain the code. Like anything else in life, if you want to excel in anything you have to be willing to sacrifice a little. What does this mean? Make a commitment to read a book a month. Take time to download a tool you have no idea about and start spiking it. Speak at a user group. Write a magazine article about your learning. Passion breeds passion, if you get infected, more often than not, others around you will want to have a "piece o dat"!!

It should be noted that the above 14 points cannot be acheived in a short amount of time, it is a proposed plan of attack for starting down a new path of development. It could take 6 months, 1 year, 2 years before you feel comfortable with all of the new techniques and practices you will be utilizing. Speaking from personal experience, it will be one of the best investments you make for your career.

Enjoy the journey!!

Imagine you have a buildfile and you have the following compile element that makes use of a couple of third party assemblies:

        <csc target="library" output="${dist.dir}\${app.library.name}" debug="${debug}">
            <sources>                
                <include name="${app.src.dir}\**\*.cs" />                
                <exclude name="${app.src.dir}\**\AssemblyInfo.cs" />
            </sources>    
            <resources>
                <include name="${config.dir}\mapping\*hbm.xml"/>
            </resources>
            <references>
                <include name="${lib.dir}\filehelpers\DotNet 2.0\FileHelpers.dll"/>
                <include name="${lib.dir}\binsor\Castle.Windsor.dll"/>
                <include name="${lib.dir}\log4net\log4net.dll"/>
                <include name="${lib.dir}\nhibernate\NHibernate.dll"/>
            </references>
        </csc>

Pay close attention to the references element. Notice how I am explicitly including the names of libraries that I want to  that "references" fileset.

Most people who are using NAnt are familiar with the concept of a fileset. Essentially it is a set of files that belong to a logical unit that you can make use of during the NAnt build process.

Assume I have another target that needed to perform a similar compile. I could just copy the references element, but that would be unnecessary duplication. What I can do is create a fileset that can be later referenced and used by other targets/tasks in the build file.

I'll start by creating the filset near the top of my build file (before any targets):

    <fileset id="deploy.lib.fileset">    
        <include name="${lib.dir}\filehelpers\DotNet 2.0\FileHelpers.dll"/>
        <include name="${lib.dir}\binsor\Castle.Windsor.dll"/>
        <include name="${lib.dir}\log4net\log4net.dll"/>                
        <include name="${lib.dir}\nhibernate\NHibernate.dll"/>                                
    </fileset>

Notice how I have changed the element to be of type filset vs references. The references element is a special subclass of fileset reserved for the csc task. You will also notice how I have given the fileset an id. It is this id that will allow me to reference this fileset elsewhere. I can now replace the fileset I was originally using in the csc task with a reference to the fileset that contains all of the references that should be used for the compile task:

        <csc target="library" output="${dist.dir}\${app.library.name}" debug="${debug}">
            <sources>                
                <include name="${app.src.dir}\**\*.cs" />                
                <exclude name="${app.src.dir}\**\AssemblyInfo.cs" />
            </sources>    
            <resources>
                <include name="${config.dir}\mapping\*hbm.xml"/>
            </resources>
            <references refid="deploy.lib.fileset"/>                
        </csc>

You can see now that the references element in the csc task now uses the refid attribute to link back to a fileset that I have already defined elsewhere in the build file. Think how many filesets you may take advantage of when building your apps using NAnt:

• sources
• references
• resources

And that is just a small sample. Streamlining and refactoring the build file is just as important as refactoring and improving the code base of the app that the build file is building.

Hopefully this has given you one more tool with which you can go and clean up some duplication that may exist in your build file.

After talking with a lot of people who have been unable to successfully download Part 1 of the TDD series, I decided I would post a link where people can download the first video again.

In order to watch this movie (offline), you will need to make sure you download the Swiff Player, for offline viewing of the flash movie.

I know it has been a while since the first video. I have finished recording the second movie and will be posting it in a couple of days to give people a chance to get back into the rhythm of where things will be going.

You can download the movie here (right click and Save As, if you want to save it to your hard drive).

During the course of these episodes you will be exposed to different ways of utilizing TDD practices along with tools that support TDD. If you do not have it already, you should download a copy of ReSharper 2.0 to follow along with what I am doing!!

Every couple of months Scott Bellware drops a post that serves as a wake-up-call for many a developer. In his latest, Scott brings up the question of sustainability. He focuses around the idea that you can’t hope to achieve sustainability without testability. As a big proponent/practioner of Agile practices I could not agree more with what Scott has to say. I also want to say a couple of more words with regards to how many developers may read Scott’s message.

A couple of times throughout his post Scott is often mentioning some point that focuses around the “limited set of approaches rampant in the mediocratic Microsoft software development world”. I often have to deal with managing these approaches being dropped into clients who have been spoon fed the typical MS kool aid. They often have a hard time initially making the switch to utilizing practices that for the longest time were not even a word in the MS vocabulary.

I should point out here that I am, and always have been a developer in the Microsoft world. Thankfully, I am pragmatic enough to realize that a lot of the approaches/techniques that were/are touted as best practices by Microsoft do not always lend themselves well to sustainability or good software development in general.

Take Design Patterns as an example. They have been around for years, and they have been getting used quite extensively in the Java space for considerably longer than in the MS world. Why is this? Community. The community around Java is huge, big enough that there are multiple viewpoints around the same topic that give beginner and senior developers alike enough contrasting information with which they can base their own conclusions. In the Microsoft world, a lot of MS devs trust MS content as gospel. Couple this with the fact that a lot of “gurus” often toured the seminar circuit dispelling the same crap that Microsoft recommended. Instead of contrasting opinions, people were fed the same information from different sources, which made it very difficult to think outside of the box. Think back a couple of years ago when people were told that you should use stored procedures for business logic. I’m not even opening up that can of worms; I am just using it as an example that was very prevalent in the MS literature. Fast track a couple of years and they are not really advocating that as a best practice anymore. It is still a viable alternative, but they have also introduced the idea of performing business logic in the Domain!! Why the change? They are learning too. Are they are leader in the field of Windows product development? Absolutely. Do they still have lots to learn about the art of software development? Absolutely.

We have to take into account that Microsoft is definitely starting to see success with adopting different approaches to its delivery methods (if but only on a small scale). Take the Composite UI Application Block as an example. It was written by an internal agile team, using Test Driven Development Practices. The result? It is the first of the applications blocks that I have looked at that I have not written off as useless.

Everyone needs to keep in mind that a lot of the concepts and practices that go along with achieving sustainability are very new to lots of developers (in any camp). Thankfully, there are a lot of excellent practitioners out there who are ready and willing to share their experiences and trials with anyone who will listen. Microsoft is also enlisting the help of many of these voices to start offering people with contrasting viewpoints on how they can achieve sustainability. Which at the end of the day can only improve the development experience for all developers in the Microsoft camp!!

Thanks to everyone who has provided awesome feedback to the current set of posts and screencast. My family and I are going on vacation tomorrow; so this will most likely be my last post for the next 2 weeks. I am making a request for people who are either following along with the screencast or interested in applying TDD to do the following:

• Submit requests for features you would like to see implemented in the sample application
• Submit aspx pages (no codebehind), that contain layouts for a screen(s) you want to see implemented using TDD
• High level client centric use cases

Here are my reasonings for this request. I have been practicing TDD for 3 years. I have been involved in the development of many applications of all shapes and sizes and technologies utilizing TDD methods. Unfortunately, I can’t bring most of you with me onto these projects (although you could bring me onto yours!!). Instead of me coming up with fictitious scenarios and features, I am counting on my readers to take the place of the client and help drive out the functionality of this “fictitious!!” application. With the submission of high-level use cases, combined (hopefully) with screen prototypes; this provides us with a scenario which is typical of well-run agile environments. A majority of the projects I have worked on have followed this approach, going so far as having the analysts creating screen mockups using plain old powerpoint!! Once the screen mockups and high level use cases are in hand, I can take the use case and break it down into measurable tasks that will become focal points for driving out small pieces of functionality using TDD.

I want this series of podcasts to become one of the places where people who are interested in seeing TDD practically applied to turn to. To do that successfully I need to depend on my readership to help drive the direction of the project. That way I will be providing information that will hopefully convey TDD in a meaningful,pragmatic way.

Thanks and get those requests in!!

With the recent buzz (in the .Net world) around behaviour driven development (mostly due to the release of NSpec). I thought I would take the time to make a quick point. BDD is nothing new to people who have already been doing TDD properly. One of the interesting side effects of even just changing the first word in the *DD term is the switch that the mind makes to realizing that TDD done properly or BDD is not about testing. TDD was never meant to be about testing the system, Test Driven Development or the lesser used term Test Driven Design is a pure exercise is designing your production code. Instead of UML class/sequence diagrams you are writing code that “specifies” how your components “behave”.  Notice the emphasis I have placed on the words specifies and behave. The whole test nomenclature can actually be quite a stumbling block for people who are wanting to do TDD effectively.

If you have taken a look at NSpec you will see that they are completely shedding the testing nomenclature. This subtle change alone can have a dramatic effect on people new to the whole “design by code approach”. Why? It enforces the concept that you are not “testing”, you are designing. If you take a look at a quick piece of code demonstrating NSpec in action:

    [Context]
    public class Example
    {
        [Specification]
        public void NewMoneyShouldHaveZeroAmount()
        {
            Specify.That(new Money().Amount).Equals(0.00m);
        }
    }

Contrast this with a ‘classic’ NUnit approach 

    [TestFixture]
    public class Example2
    {
        [Test]
        public void TestNewMoney()
        {
            Assert.Equals(0.00m, new Money().Amount);
        }
    }

Functionally these two pieces of code are equivalent. Notice , however, that the use of the specification friendly terminology provided by NSpec does make intent of the code a bit easier to read (in my opinion).

NSpec as a framework looks promising, I’m not sure if it is ready for prime time yet, but again it is just a framework to aid in the ‘practice’ of BDD.  I think that BDD is the next natural step to enable people who may be struggling with TDD to finally realize that it is not about testing at all, it is about design.

As a consultant who is often sent in to mentor teams of developers on Agile practices, it is always interesting to see the reaction that a lot of developers have to the practice of Test Driven Development. The reaction that I almost always see (initially) is one of uncomfortability and apprehension. Looking back almost 3 years to when I started practicing test driven development, I have complete empathy for people in that situation. In my personal opinion, when you undertake the task of getting to grips with TDD you have to ask some really hard questions about “what you think you know”. I have found that having a solid OO background is paramount in utilizing TDD effectively on software projects (assuming the OO paradigm is in effect). This is often a time when many developers have to stop and really question their true solid knowledge of fundamental OO concepts. Often times, developers are quite surprised at how much they still have to learn about good object composition and responsibility assignment.

I have seen two different kinds of reactions to this realization. People can choose to humble themselves and realize “hey, I’m willing to admit that although I thought I had OO concepts down pat, I obviously don’t and want to make a change”. These people are “highly coachable”. They are willing to relinquish any assumptions they have about their knowledge of object oriented concepts and essentially relearn a lot of the basics in order to make themselves more effective developers. Of course, this is a process that can happen quite naturally when they are being coached by someone who is trying to teach them  TDD. The other set of people are the ones who are not willing to admit that they may not know as much as they think. They will initially fight the coaching every step of the way because “you can’t teach me anything new”. I have definitely run into my share of these people over the years. Even then, I do not like to put these people into an “uncoachable” category. I believe that once you have gained people’s trust and they realize that you are actually there to add value to their project/skillset, even people who seem “uncoachable” often open up to new ideas. It just takes time.

I like to think of learning TDD as equivalent to learning to snowboard. Lots of snowboarders who have been involved in the sport for a while often encourage new learners to take at least one lesson from a seasoned snowboarder. Half of the new riders will attempt to learn to snowboard on their own. Will they get it? Yes. Will it take longer than if they had picked up tips and tricks from an experienced rider? Yes. Is there a possibility they will develop bad technique? More than likely. Learning TDD on your own is actually very similar. There is no better way to learn TDD than to pair with someone who has been involved in the process for a while. They will be able to pass down techniques and tricks that you can immediately utilize to improve the quality of the tests that you write. They will be able to teach you about the value of using mock object and dependency injection to write more loosely coupled code. They will be able to allow you to identify how to test objects in isolation and how not to test too much at a time.

This brings me to talking about humility for the coach. It does not matter how great I think TDD or other agile concepts are. Often times, teams I go into work with are going to be experiencing these concepts for the first time. I cannot go into these environments with a “Holier than thou” attitude and expect them to be receptive to what I have to show them. Unfortunately, I often have to deal with other issues being the “senior” guy sent in to train these development teams. Anyone who knows me, is aware of how young I look (something that I definitely got hassled for when appearing on DNRTv). It definitely is a cause of surprise when I am sent into meet with new clients and I am being presented as the senior resource and the first thought that pops into the clients heads are “Is he even out of school!!”. Of course, any assumptions about my age are quickly put to rest once people realize I have been married 10 years and have 4 children (the oldest being 9 years old). Once they get over that bombshell!! I can get to the task I was sent in to do. Again, mentors and tech leads, I have to stress this point loud and clear

• Just because we ‘may’ have more experience and knowledge than the people we are coaching, we are in no way better than that person in any way shape or form.

People might be saying, “well JP, this is just common sense”. I wish it were true. Unfortunately I see this every day, and whole sets of people are being alienated because they are being made to feel inferior as a developer; and worse, as a person. One of the biggest problems a lot of people have when trying to work with people who are coaching them on TDD principles is the fact that the coach really does not have the patience to teach in the first place. Why is patience paramount? 80% of the time spent teaching TDD will actually be time spent unravelling years of bad habits that need to be broken to become effective at TDD.  Often times, these habits are things that the coach also had to break when starting down the TDD path. Which is why it is essential for mentors and coaches to “Remember where you were when you started down this path”. TDD is a paradigm shift for developers, it takes time (just like good OO skills take time and practice to hone) to get:

• A – Comfortable with the shift
• B – Proficient with the application of TDD

In conclusion I would like to finish by saying that people can have great success adopting TDD when the right person/people are there to aid them in the process. It takes humility on both parties involved to ensure that the transition is as smooth as it can be. There is a lot of buzz in the industry around TDD and agile concepts right now, and I personally think that is a good thing. There are a handful of good TDD practitioners out there in the blogsphere / presentation circuit who are extremely pumped about spreading the “good news” about TDD. With all that said, every developer individually needs to determine whether TDD is something that works for them. Like anything else in life/software, you need to give it an honest educated shot before discounting it completely. My last piece of advice regarding TDD is this. Anything new in life/software always makes us feel a little uncomfortable. It is our responsibility to either ignore something new, or give it an “educated” shot, before discounting it completely. Don’t discount TDD until you have had the opportunity to see/use it effectively. It has personally changed the way I develop software, and I could honestly say that I couldn't go back to not using it.

If you ever need someone to come in and coach your team / give a presentation on TDD don’t hesitate to contact me. It would be an honour.

As one of my readers kindly reminded me. I mentioned in the CC.Net video that I would make the CC.Net configuration section for the project demo available.

Here it is:

<cruisecontrol>
 <project name="AdventureWorks">
    <workingDirectory>C:\root\development\citools\cruise\checkouts\adventureworks</workingDirectory>
    <artifactDirectory>C:\root\development\citools\cruise\builds\adventureworks\artifacts</artifactDirectory>
    <webURL>http://localhost/ccnet</webURL> 
    <modificationDelaySeconds>10</modificationDelaySeconds>
    <publishExceptions>true</publishExceptions>
    <triggers>
      <intervalTrigger seconds="60" />
    </triggers>
    <state type="state" directory="C:\root\development\citools\cruise\builds\adventureworks\state" />
    <sourcecontrol type="svn">
  <trunkUrl>file:///C:/root/development/svnrepo/playground/adventureworks</trunkUrl>
  <workingDirectory>C:\root\development\citools\cruise\checkouts\adventureworks</workingDirectory>
 </sourcecontrol>
 <tasks>
      <nant>
        <executable>c:\root\development\citools\nant\bin\nant.exe</executable>
        <baseDirectory>C:\root\development\citools\cruise\builds\adventureworks</baseDirectory>       
        <buildFile>cruise.build</buildFile>
        <targetList>
          <target>all</target>
        </targetList>
        <buildTimeoutSeconds>300</buildTimeoutSeconds>
      </nant>
    </tasks>
    <publishers>
      <merge>
        <files>
          <file>C:\root\development\citools\cruise\checkouts\adventureworks\build\*Test-Result.xml</file>
        </files>
      </merge>
      <xmllogger />
    </publishers>
 </project> 
</cruisecontrol>

Of course, you will need to ensure that you replace any occurrence of C:\root\development with a location that you want to use on your own machine.

It seems like quite a few people had trouble watching the videos for the last post that I made. Based on some good feedback I have decided to make it available for download as a flash file so that people can watch it at their leisure. The download file is a 50MB zip file that extracts to a swf (flash) file.

If you have any problems accessing the files please let me know.

• Download the flash video here
• I will post the google link once it is verified.

Last time we left off adding in the compilation of the web project to our build process. If you remember back to when we introduced the database we brought in the concept of template files and replacement tokens that could be used to allow for multiple developers on a project with disparate machine configurations to build using the same build file without any changes required. What we want to do now is go the final step and take our standalone build file that is currently being used by individual developers (whether or not they are on a team), and use it to centralize the build process. We are going to set up an environment that a multi developer team can use to introduce a CI process into their environment. CI (for those of you that don’t know) stands for Continuous Integration. Let me stress something very important here. CI is a process, not a tool.  If you want to read a concise definition of CI, check out Martin Fowlers article on the subject. That being said, there are a lot of tools that can aid you in introducing CI into your developer environment. We have already been taking advantage of a couple of these tools:

• NAnt
• NUnit

The new tool that we are going to introduce today is CruiseControl.Net. CC.Net is basically an automated build server. You would typically set it up so that at regular intervals it would poll the source code repository and see if there are any changes, if there are it would:

• Update it’s local copy of the source code from the latest version in the repository.
• Perform a build against it’s local code base
• Run all unit tests, acceptance tests etc
• Generate status reports on the health of the build

Obviously, this is a very high level description of some of the things CC .Net can do. 

This blog post could turn out to be huge, so to save my wrists I am going to try something a little bit different. I am posting a screencast that demonstrates the entire process required to:

• Place a project under source control using Subversion
• Installing CC.Net
• Configuring CC.Net to build a project.

This is a note out for all of the people who have been following along in the NAnt starter series, that tomorrow I will be posting one of the final entries in this series. This episode will be all about getting a Continuous Build environment set up with CruiseControl .Net. Topics that are going to be covered are:

• Installing Cruise Control .Net
• Setting up the build box for project building
• Creating the repository
• Configuring the build box to build the project
• Integration with CC.Net

That is a high level overview. As you can imagine, it is a lot of information, too much for me to write about (in a practical amount of time). This is why I am going to do a screencast on my computer that will be made available for everyone to watch. One thing you will want to do is read my Applied Test Driven Development For Web ApplicationsPart1 post and download the sample code as that is what you will need to follow along with the screen cast. I am choosing to use that code base as it will be the code base that will be build upon in the Applied Test Driven Development series, where we will build out a web application (against the adventureworks database) using TDD techniques.

After watching the video you will have a great starting point from which to start practically using CC.Net in your own environment. To save yourself some time I suggest going to download CC.Net from here. You don’t need to install it yet, as I will walk through the install process tomorrow!!

I have been promising for a long time to start a series that details the creation of a project similar to the one that I presented on my first set of DNRTv episodes. Here is the beginning of that promise!! The goals of this series is to develop a highly testable web application that demonstrates a lot of the principles that can be utilised when developing a web (or any) application using Test Driven Development. I have chosen to base the examples around the new AdventureWorks database. Why AdventureWorks you may ask? Since it is the successor to Northwind, you are going to see (or already have) many examples/demos that utilise it as a DB. It stands to reason that a lot of the techniques and approaches that I am going to show you, will be counter to what is in the mainstream MS world right now. This is not a bad thing, it is always good to open your eyes to new ways to accomplish tasks!!

In this episode, I am just going to start by discussing solution structure for the project as well as the building of the database. This is by no means meant to be an introduction to NAnt, if you want to see how NAnt can be utilised as build tool for your projects then read my NAnt Start Series. Download this zip file and you will be able to start off at the same point that I am starting at. Drop the zip file in a folder you typically do your development and unzip it to that location:

Once you have extracted the contents of the build file there should now be a directory named adventureworks.

The first thing you will need to do is go into the adventureworks directory (from this point referred to as the trunk) and copy the local.properties.xml.template file to a file named local.properties.xml (don’t delete the local.properties.xml.template file):

With that taken care of, you will need to go in and edit the local.properties.xml file (not the template) and change any settings that may be specific to your machine:

<?xml version="1.0"?>
<properties>
 <property name="sqlToolsFolder" value="C:\Program Files\Microsoft SQL Server\90\Tools\Binn"/>
 <property name="osql.ConnectionString" value="-E"/>
 <property name="initial.catalog" value="AdventureWorks"/>
 <property name="config.ConnectionString" value="data source=(local);Integrated Security=SSPI;Initial Catalog=${initial.catalog}"/> 
 <property name="database.path" value="C:\root\development\databases" />
 <property name="osql.exe"  value="${sqlToolsFolder}\osql.exe" />
</properties>

Pay special attention to the database.path property. You can change the value to point to a different directory on your machine. Make sure that the folder exists, as the build process does not create this folder for you (it could, but I chose not to). Another setting that might vary on your machine is the osql.ConnectionString property. This is basically the connection parameters that you would need to specify if you used OSQL from the command line. For me, I use integrated windows authentication so I can just use the -E switch. You will have to experiment with your settings (you might even need to specify a server name etc).

Once you have changed the properties you can open up a command prompt pointing to your trunk directory. From the command line run the command “build run”. If all of your settings are configured properly (and you have a local instance of IIS), you should see a blank web page pop up in your browser:

Last but not least, once you have closed down the browser, you can run the following command from the command line “build builddb”. This will copy the adventureworks database files located in the [trunk]\sql\original directory and place them in the directory that you specified in the “database.path” property of your local configuration file. It will also run a sp_attach_db command and it will name the database using the name you provided in the “initial.catalog” property of your local configuration file.

I have explicitly chosen not to build the DB from scripts, why? I had a hard time finding any original SQL scripts for the AVWorks. If anyone feels like taking the time to create script files that we can use (as well as the accompanying seed data) please let me know.

The main build targets that we will be using during the course of these walkthroughs are “build test” and “build run”.

Let’s take a quick look at the initial solution structure (double click on the AdventureWorks.sln file, this is a VS2005 projects):

So far we have a Web project, a Presentation project, and a Presentation.Test project. Pretty standard fare. Right now the 2 classes that are in each of the Presentation, and Presentation.Test project are just there so the “build test” target in the build file will execute properly. We will replace both of those classes with meaningful classes next week.

Ok, we are ready to start. Take a look around (there’s nothing much to see right now), read my NAnt Starter Series if you have’nt already. And most important, submit requests for what you would like to see in this project. Keep in mind that I am going to try and use it as a vehicle to teach both TDD and good development practices (design patterns, refactoring etc, OO). Next week I will start by building a screen similar to the one that I created for DNRTv, once I have gotten completely through that example we will have a fairly good ground from which to branch out from. I have already talked to a handful of people and have a good idea of what they would like to see demonstrated. If you have’nt got your request in, now is the time to do it. If you can’t comment on this blog post email me directly at bitwisejp@gmail.com.

Here are some ideas to get you thinking:

• Manageable Databinding
• Passing information between pages
• Master/Detail pages
• Managing master pages better
• Ajax
• Layered Architecture
• Validation

Let the coding begin (almost!!).

For readers of this blog you are no doubt aware that I am a practitioner of TDD and I have a passion for at least demonstrating its benefits to other developers. I had a great conversation with Kyle Baley and Wade Grandoni the other day, and I stressed the fact that although I believe heavily in the value of TDD, I also realize that it is just another tool that developers can “choose” to add to their arsenal. Would I personally develop not using TDD, probably not. Do I know that before TDD came along that there were many successful projects delivered on-time and on-budget, absolutely!

That being said, there is a reason why many developers have a hard time believing the benefits of TDD. One of the biggest issues which is often a stumbling block for many developers new/attempting TDD is the fact that it does represent a significant paradigm shift into the software development process. “You want me to write a test for a method that doesn’t exist yet on a class that doesn’t exist yet??” In my opinion, this statement alone represents the reason why I believe that the shift is an even bigger one than the one many of us faced years ago – The shift from procedural coding to OO programming.

I am sure that there are few of us today who could argue against practical reasons for utilizing OO as a vehicle to compose applications. The same holds true for TDD. At first it can be something that looks so different from what you are used to that you do one of two things:

• Shrug it off completely as a waste of time
• Look into the questions popping up in your mind

It is the second group that can still continue to have a hard time with the process. Why? Again, remember back to when you were learning to code/think in objects? Chances are you had the help of a few good books, and mentors who had run the Object race, whom you gleaned a lot of good information/best practices from. Because TDD is still a relatively new practice for the .Net community, there is a definite shortage of experts who people can turn to for personal coaching. Now I say shortage, there are a lot of TDD practitioners and gurus out there, but not nearly as many as plain old OO gurus. Why am I mentioning this? Often in the first couple of weeks of attempting TDD on anything but a trivial project, people who are trying to do it on their own get frustrated, and sometimes it is at this point that they dismiss TDD as a waste of time and “impractical for enterprise development”. Unfortunately, this frustration can often be a result of the fact that correctly applying TDD means having a handle on some plain old fashioned clean object thinking. A seasoned TDD developer can help walk you down the path of interface based programming. They can extol the values of dependency injection and layered architecture. All the while tying these principles back to how they relate to the TDD software development process.

Lastly, the biggest reason I think people have a hard time buying into TDD is the only time they get to see it in action is by the “experts’ who can only use it to demonstrate a “small” piece of a larger application. I admit, I definitely fall into this category. Unfortunately what they can’t see is how TDD can literally be applied to build out the functionality of enormous large scale enterprise applications. Why? They can’t join you on your project on a daily basis. They can’t see how just because you are using TDD that the SDLC hasn’t disappeared. They can’t see that in an agile environment a large part of the test code that you write is a direct result of hourly interaction with the business users, who are there helping the developers carve out the functionality. They can’t see the fact that even though you are using TDD that other types of testing are not forgotten.

I am not a purist. I believe TDD is a great vehicle for delivering apps into the hands of users quicker. Do I think that a developer who doesn’t use TDD is a less skilled developer. Absolutely not. One thing you can’t be in this industry is dogmatic. Everyone is entitled to their own opinion. My personal opinion – I would not develop software without using a TDD approach.

Currently some of my links in dasblog are not working correctly and some people are having problems with accessing the entire NAnt series of posts. To ensure that everyone can read them in their entirety here are the links to the current 6 posts:

• Automating Your Builds With NAnt –Part 1

• Automating Your Builds With NAnt – Part 2

• Automating Your Builds With NAnt – Part 3

• Automating Your Builds With NAnt – Part 4

• Automating Your Builds With NAnt – Part 5

• Automating Your Builds With NAnt – Part 6

• Automating Your Builds With NAnt – Part 7

Enjoy.

Just got asked a question by Scott Cowan :

Q:  is there a way in nant to run a call for each .sql file in a dir ?

A: If you wanted to execute the scripts for a whole directory of sql files (and the order of the files running is not important), then you can take advantage of the NAnt <foreach> task.   Here is an example of a target that you could set up to run all of the sql files in a specific folder: