This script is for a table function of all dates for a given range.

USE [MyDB]
GO
/****** Object:  UserDefinedFunction [dbo].[fn_GetCalendarDateTableAllRange]    Script Date: 01/23/2012 11:12:40 ******/
IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[fn_GetCalendarDateTableAllRange]') AND type in (N'FN', N'IF', N'TF', N'FS', N'FT'))
DROP FUNCTION [dbo].[fn_GetCalendarDateTableAllRange]
GO
USE [MyDB]
GO
/****** Object:  UserDefinedFunction [dbo].[fn_GetCalendarDateTableAllRange]    Script Date: 01/23/2012 11:12:40 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE FUNCTION [dbo].[fn_GetCalendarDateTableAllRange]
(    
@minDateInclusive DATE 
,@maxDateInclusive DATE 
)
RETURNS     
@CalendarDateAllRange TABLE
(CalendarDate DATE    )
AS
BEGIN
IF @minDateInclusive > @maxDateInclusive
RETURN
DECLARE @loopCurrentDate DATE
SET @loopCurrentDate = @minDateInclusive
WHILE @loopCurrentDate <= @maxDateInclusive
BEGIN
INSERT INTO @CalendarDateAllRange VALUES  (@loopCurrentDate)
SET @loopCurrentDate = DATEADD(DAY,1,@loopCurrentDate)
END
RETURN
END
GO

This can be useful if I want report of how many customers enrolled with my service on each day of the month.
Lets say I had a table of customer enrollments with a date of enrollment for each.

Customer Enrollment Table

Enrollment Counts by Date

Enrollment Graph #1

Enrollment Counts by Date with Full Dates

Enrollment Graph #2

USE [MyDB]
GO
/****** Object:  Table [dbo].[CalendarDateAllRange]    Script Date: 02/17/2012 22:20:18 ******/
IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[CalendarDateAllRange]') AND type in (N'U'))
DROP TABLE [dbo].[CalendarDateAllRange]
GO
USE [MyDB]
GO
/****** Object:  Table [dbo].[CalendarDateAllRange]    Script Date: 02/17/2012 22:20:19 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[CalendarDateAllRange](
[CalendarDate] [date] NOT NULL,
CONSTRAINT [PK_CalendarDateAllRange] PRIMARY KEY CLUSTERED 
(
[CalendarDate] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
-- Now populate the dates in the table
DECLARE    @minDateInclusive DATE 
DECLARE @maxDateInclusive DATE 
SET @minDateInclusive = '1/4/2010'
SET @maxDateInclusive = '5/2/2012'
DECLARE @loopCurrentDate DATE
SET @loopCurrentDate = @minDateInclusive
WHILE @loopCurrentDate <= @maxDateInclusive
BEGIN
INSERT INTO CalendarDateAllRange VALUES  (@loopCurrentDate)
SET @loopCurrentDate = DATEADD(DAY,1,@loopCurrentDate)
END
SELECT * FROM CalendarDateAllRange

Scripts available below
fn_GetCalendarDateTableAllRange.sql
DropAndCreateCalendarDetailTable.sql

In this example I’m using SSIS to write a .NET-like executable application that grabs data and “processes” it. Using SSIS is a nice alternative if your application is not “business-logic” heavy, and that way you can avoid a code-heavy program that may be more flexible but less robust in the process.

    Background: Energy Suppliers must leverage pipeline transportation systems to transmit Natural Gas to local Utilies to be distributed to customers. Each day, the pipeline accepts nominations for transportation the following day. The Supplier must identify all counter-parties and indicate the date and amount to be delivered. Additionally, they must properly calculate the line-loss from delivery to destination, which is typically 5%.

Here are the steps at a very high level:

• Query for an un-submitted “open” set of gas nominations that I need to submit to the pipeline.
• Use the Nomination Set to load the nominations themselves.
• One-by-one, submit each nomination to the gas pipeline’s web service
• Log the output of each submission
• Close the Nomination Set

Setup

Nomination Tables
Sample Data from these tables here.

Create SSIS Package and Setup Variables

New Package

Variables

• NominationSetID – The ID of the current Nomination Set that we’re processing.
• ScheduleDate – Loaded from the Nomination Set. Used as a filter when querying Nominations to submit.
• TransportationServiceURL – Loaded from the Nomination Set. Will be used by our web service task as the URL to call.
• TraderCode - Loaded from the Nomination Set. Used as a filter when querying Nominations to submit.
• NominationSector - Loaded from the Nomination Set. Used as a filter when querying Nominations to submit.

• NominationData - Will be used as an in-memory table for iterating through our nominations (more on this later).

• Loop_CurrentNomination – Used within our ForEach Loop. Represents the current Nomination Data to submit.
• Loop_NominationOutput – Used within our ForEach Loop. Represents the output from submitting our nomination to the web service.

Load an Open Nomination Set

Load Open Nomination Task

SELECT TOP 1 
NominationSetID 
,[NominationSector]
,[PipelineEndpointURL]
,[TraderCode]
,NominationSetDate = CONVERT(DATETIME,[NominationSetDate])
,[Closed]
FROM [dbo].[NominationSet]
WHERE Closed = 0

Set Result Set To Single Row

Map Result Set To Variables

Edit Breakpoints

Using the Watch Window to verify our variable assignments

Load Nominations

SELECT [NominationID]
,NominationData = 
[Shipper_ContractNumber]
+ ' | ' + [DeliveringParty_ContractNumber]
+ ' | ' + CONVERT(VARCHAR(50),[StartDate],112)
+ ' | ' + CONVERT(VARCHAR(50),[StopDate],112)
+ ' | ' + [ReceiptMeterNumber]
+ ' | ' + CONVERT(VARCHAR(50),[ReceiptAmount])
+ ' | ' + [DeliveryMeterNumber]
+ ' | ' + CONVERT(VARCHAR(50),[DeliveryAmount])
+ ' | ' + [ReceivingPartyContractNumber]
,[ScheduleDate]
,[Sector]
,[TraderCode]
FROM [dbo].[Nomination]
WHERE
ScheduleDate = ?
AND Sector = ?
AND TraderCode = ?

Set Result Set to Full Record Set

Set Output to our NominationData variable

Loop through Dataset and Process

Add a Foreach Container

Point enumeration to the NominationData collection from previous step

Map the current row to our variable Loop_CurrentNomination

Submit the Nomination

Set Method Call and pass in our variable Loop_CurrentNomination

Set output to our variable: Loop_NominationOutput

Debugging our Web Service Call

Logging the Output

Add Data Flow Task to our Foreach Loop

Our Data Flow Task to Log our output

Data Flow Task Step 1

Data Flow Task Step 2

Data Flow Task Step 3 - Map Columns to Flat File

Log file with our Nomination submission results

Closing our Nomination Set

Query to Close Nomination Set

Configure our input to our query

Conclusion

Setting up access control permissions on Windows 7 for a new website hosted under the wwwroot is not difficult, because you don’t have to do anything. But if you’re hosting a website from a virtual directory outside of the wwwroot you might get this error:

The requested page cannot be accessed because the related configuration data for the page is invalid

    After close examination this is a permission issue. You may also get this error if you’ve only solved half the problem:

You do not have permission to view this directory or page because of the access control list (ACL) configuration or encryption settings for this resource on the Web server

• IUSRS - The new default account used for anonymous authentication
• IIS_IUSRS – A new built-in group serving as a container for all application pool identities

    By default, these objects have access to wwwroot (IUSR has access under the Users group).

1. Navigate to your website’s directory. Right-click and bring up the Properties menu. Under the Security menu, click Edit to change permissions.





2. Click Add to add another object to the access list. Type in “IUSR” and click Check Names to verify. Click Ok.





3. By default the typical “Read” permissions should be checked. Repeat step 2 typing in the group “IIS_IUSRS” instead.





4. Click Ok to close the properties dialogue.

Now you’re ready to rock’n’roll with a website hosted under IIS 7! For a more detailed explanation of the new entities please refer to the article below:

    The Head-First book series is incredible, possibly the most not-boring set of technical resources I've ever come across. Of course they have one for IOS Development, decked out and up-to-date with XCode 4 too!

HeadFirst iPhone Development

    The Insta-Email app is one of the first "complete" apps that you create as an exercise. It demonstrates the use of Views, View-Controllers, IBActions and IBOutlets, and the first iPhone "data-control".

XCode 4 IDE

Application Lifecycle

Choose an Activity. Then choose your Feeling

Press "Send Email" to inform your significant other!

The Email is sent with the message!

The Root View (UI)

The Sub-Views that comprise the Root View

• A few Labels
• A UIPickerView for choosing the Activity and Feeling
• A UIButton for sending the Email

Outlets and Actions

    The way you wire-up events and access your Views ("controls" for you Microsoft people) is through IBActions and IBOutlets. The IBAction sendButtonTapped is declared as the delegate method to intercept an action from the UI. The action is then wired up using Interface Builder.

Wiring the button-click to the IBAction

From there, the code to send the Email is executed (won't go into the details of how that's done for now).

#pragma mark
#pragma mark IBActions
-(IBAction) sendButtonTapped:(id)sender
{
int actionIndex = [self.emailPicker selectedRowInComponent:0];
int feelingIndex = [self.emailPicker selectedRowInComponent:1];
NSString* actionMessage = [activities_ objectAtIndex:actionIndex];
NSString* feelingMessage = [feelings_ objectAtIndex:feelingIndex];
NSString* theEmailMessage = [NSString stringWithFormat:@"I'm %@ and feeling %@ about it.", actionMessage, feelingMessage];
//NSLog(@"%@", theEmailMessage);
if ([MFMailComposeViewController canSendMail])
{
MFMailComposeViewController* mailController = [[MFMailComposeViewController alloc] init];
[mailController setMailComposeDelegate: self];
[mailController setSubject:@"Hello Xuan!"];
[mailController setMessageBody:theEmailMessage isHTML:NO];
[self presentModalViewController:mailController animated:YES];
[mailController release];
}
else
{
NSLog(@"Sorry you need to setup mail first");
}
}

    The IBOutlet allows me to connect a variable declared in my Header File to a control in my View. Without IBOutlets, the code in my ViewController would never be able to access or manipulate anything on my View. To do this, I must declare a variable in my Header File of the same type as the View I want to connect. Then I use Interface Builder to connect the two.

Wiring the View-Controller to the UIPickerView using IBOutlet

This allows my code to access the UIPickerView at will.

//
int actionIndex = [self.emailPicker selectedRowInComponent:0];

A View that needs a Data Source

Working with a data-driven view in Cocoa Touch is very different from a data-driven control in ASP.NET. In the latter, all you really need is a data-source collection and you're good-to-go. With the former, you must designate a class to implement each of the protocols (ALMOST like an interface in .NET) required by the view to function.

The first is the UIPickerViewDataSource. This protocol features the following method signatures for helping to define the rows and components in the view:

• numberOfComponentsInPickerView
• pickerView:numberOfRowsInComponent

//
#pragma mark - 
#pragma mark Picker Datasource Protocol
- (NSInteger) numberOfComponentsInPickerView:(UIPickerView *)pickerView
{
return 2;
}
-(NSInteger) pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component
{
if (component == 0)
{
return [activities_ count];
}
else
{
return [feelings_ count];
}
}

The second is the UIPickerViewDelegate, which provides methods for defining templating and the content that populates the view.

• pickerView:rowHeightForComponent
• pickerView:widthForComponent
• pickerView:titleForRow:forComponent
• pickerView:viewForRow:forComponent:reusingView
• pickerView:didSelectRow:inComponent

//
#pragma mark -
#pragma mark Picker Delegate Protocol
-(NSString *) pickerView:(UIPickerView *)pickerView titleForRow:(NSInteger)row forComponent:(NSInteger)component
{
if (component == 0)
{
return [activities_ objectAtIndex:row];
}
else
{
return [feelings_ objectAtIndex:row];
}
}

    In accordance with the Apple Human Interface Guide, this was more like a Utility application. The next application on our list will be a Navigation-based application.

Click for demo

     This is a project that I've been working on in my spare time. My development team has a shiny plasma on the wall the Silverlight Toolkit has some very nice data visualization tools and I've been looking for an opportunity so I just put 2 and 2 and 2 together.

     The flow is based on the concept of Paradigms, which are contained in a Paradigm Deck. For this example we load a Paradigm Deck called "SALES-DEMO". This deck consists of 2 Paradigms, one entitled "Year Over Year Earnings". This Paradigm contains 2 Paradigm Controls. The one in the top zone is a graph of year-over-year earnings for a company from 2010 to 2011. The bottom control contains a table with the same information shown in the top control. The second Paradigm entitled "Sales By Channel" contains 2 Paradigm Controls. Notice that the left Paradigm Control in this Paradigm uses the same template table as the bottom Paradigm Control in the last Paradigm. These controls are dynamically driven off of a separate meta-data store.

     This project was built on Silverlight 4 (originally I used Silverlight 5 but the runtime is not officially available to the common people). I also used the Silverlight 4 Control Toolkit available from CodePlex, specifically the Data Visualization controls.

     This was my first experiment with the Model-View-View Model pattern. The most challenging thing however was dynamically loading the views and graphs off of a separate data store. More detail on that in a later post.

NOTE - This post is NOT an introductory guide to Objective-C. What may resemble "Guidance notes" are merely my learning accounts

    My co-workers started an iOS study-group 5 weeks ago. I won't stay in my comfortable .NET shell because you never know where the demand-side of the market will go, and where-ever it should be 5 to 10 years from now, I plan to stay on the supply-side. I didn't start sooner because of laziness and fear of the unknown, two natural tendencies that would serve us well to defy. But thanks to peer pressure I'm on this road and I'm starting a series of posts to recap my accounts.

I'm in a slightly unique position, because my only experience with C++ was one semester in high-school before transferring to Java. I'm one of those youngsters that old-timers gripe about, never having to manage my own memory. But now I'm finally witnessing relics of C, the great ancestor of C#.

Understanding What I'm Dealing With

    Objective-C is to C what C# 3.0 is to C# 2.0. By that I mean Objective-C is an extension of C that provides Small-talk "messaging" features to the base language, though the runtime is the same. Likewise C# 3.0/3.5 adds features to C# 2.0, such as automatic properties, extension methods, and LINQ.

Separation of Files - The Header and Body (a.k.a. interface from implementation)

    The first example of "why do I have to do this when the compiler already knows what I want?". The header file provides a forced documentation of your class members. Figuring out class members is not a "one-glance" routine in .NET. But inspecting the header file is. And because the header file is the place for instance variable declarations, it truly forces the implementation file to be a place for pure implementation.

Smalltalk Messaging

    Freedom from the burden of type-checking? It's funny, and ironic. My friend told me the history of programming languages in which we've gone back and forth from loosely typed languages that let you "pass anything to everything" like C, to strongly typed languages where not only is there a net RIGHT under the high wire, but captain compiler won't let you out of the nest without a thorough type-check. But the messaging syntax allows you to decide your level of enforcement:

• If you want the object-oriented (OO) mutable style of C# then you use the dot (.) syntax. But the messaging syntax provides a dynamic-typed functional approach. I guess what impresses me is that I've never seen the two incorporated into the same language
• I can't yet vouch for the Apple developers' claim that this is more readable, but I intend to press on using it if this is truly the more common standard this side of the fence

Memory Management

    I'm guessing that computer science majors wound up relating memory management in C back to semaphores from Operating Systems. It actually happened the other way around for me. I was watching the Stanford Video series and heard someone mention semaphores after learning about allocation and release counters. I Google-ed semaphore and found the resemblance uncanny.

Simple vs. complex types
You don't have to allocate or release simple variable types, since they don't use pointers. You do have to for complex types. Object instances are managed with pointers, so anything that was pointed to (and thus resides on the heap) must be de-allocated.
I was surprised to find out that there IS a garbage collector, but it will only collect on released memory. Any pointer that is allocated must be de-allocated or it will remain uncollected

Semaphore logic
In a nutshell, here's how it works. Just as multiple variables can reference the same instance in C#, multiple pointers can reference the same memory location. The run-time increments the allocation counter for every pointer that has been added. The run-time decrements the counter for every pointer that is released. When the last pointer is released, the memory is reclaimed.

Synthesizing Properties

    The cool version of Automatic Properties. I think it's ironic that with header files and pointer management, a lot of things are explicit. Accessors(not in the English dictionary?) through property synthesis are implicit. By synthesizing property members you just kind of know that the accessors are there.

Next Time...

    After that retrospect, I got to pondering the question of which language is "better". Alright, that'll be next time's topic.

Below is a summary of my work on one of the Silverlight 3 Hands-On Labs. This lab focuses mainly on data layout and retrieving data from LINQ to XML, or a WCF Service. My walkthrough contains the following concepts:

1. Defining Layout using Grid and Canvas
2. User Controls
3. The DataGrid control
4. Data Context-driven data binding
5. The Factory Pattern (Design Pattern)
6. Calling asynchronous methods and delegating a call-back method
7. Configuring and calling a WCF Web Service
8. LINQ to XML
9. LINQ to SQL

Overview

To use the Inventory Manager, the user can search for products by SKU or by Name.
If the user searches by SKU, a single product's information will be displayed in a Grid layout.
If the user searches by Name, all products whose names contain the search text will display in a Data Grid.

Layout - A
The top section consists of a border wrapped around a Grid layout control (a common practice).

The Factory Pattern is used to return an object implementing the expected interface. The caller neither knows nor cares about the implementation details of the data provider. It just knows that whatever is returned implements the following interface

First, the call-back is wired to the event that signals the completion of the operation.Second the call-back is called when the event is fired. The object returned in the result is bound to the DataContext of our grid.

Data Context-driven binding in Silverlight means you don't need a specific data control to support data binding. Just about any property of any control supports binding. The respective "source" is the most specifically defined data context.

Think of it like scope in terms of programming. In this case, I'm binding a Text property of my control to the property name ProductID. Silverlight will traverse up the control tree and find the most specifically defined scope in which the data context has been bound. In this case, the Grid has been bound to a ProductInfo object. Just as easily, the entire UserControl could have been bound to an object which would have served as my data source.

The result is that my Inventory Detail Grid (gridInventoryDetails) shows the values of the ProductInfo object returned.

Layout - B

The next walkthrough will be a search by name, which uses an alternative layout:

For this example we auto-generate out columns to avoid the grunt-work of customizing them. I set my ItemsSource property to just "Binding" as opposed to "Binding [Some Property to bind to]" What this means is that my Datagrid will be bound to whatever object happens to be assigned to my local Data Context.

Walkthrough - Search by Name Against an XML Data Store

The user clicks on the radio button "Search by Name", types in a search term, and clicks "Search". Once again this triggers our event handler. This time we have a block to handle the search by name.

And here are the method implementations used to search the XML data and return a generic list of ProductInfo. The Products.xml file is loaded using our utility class (included within the project) and we use LINQ-to-XML to search the record we need. We use a helper method to hydrate a generic list of ProductInfo and then raise our event to signal to the UI that we're done.

Walkthrough - Search by Name Against a WCF Service

Finally, we'll change our factory one more time to use an Inventory Manager that calls a separate WCF Service.

Setting up a WCF service for Silverlight
In a simpler scenario you can setup your WCF service on the same site that is hosting your application. This will allow your Silverlight client to automatically authenticate back to its parent site. But for demonstration I'm going to set this up on a separate web site.

Make sure you specifically choose the type "Silverlight-enabled WCF Service" when adding your service. This is still a WCF service, but the difference is in the configuration setup. Silverlight only supports basic HTTP binding, so your web.config must be configured NOT to explicitly use wsHTTPBinding like most WCF services would be.

I'm admittedly unclear on the full details on that last portion. I've only scratched the surface on the possibilities that WCF can provide through custom meta-data, but knowing what you need from WCF vs. trying to grasp it all has been a catch-22 for most developers. That's why there have been attempts to simplify connectivity for the most common situations.

I add a Linq-To-SQL provider against the renowned AdventureWorks database. And I only want 2 tables: Product and ProductInventory. I call it AdventureWorks.dbml.

For this example here is the implementation of the method GetInventoryByName(). I use my LINQ-to-SQL generator to search for my item by name and hydrate a generic list of ProductInfo instances.

Finally I need one more thing to make this work. In a simple scenario where my Silverlight application is served through the same website that contains my service, the client-application automatically authenticates to its parent website. But if I'm on a different web-site, I need a way to expose my access to my client application. This is achieved through the file clientaccesspolicy.xml.

Without going into detail, this implementation basically states that anyone from any domain URI to access my web service. The clientaccesspolicy.xml file must reside within the root of your web application.

Conclusion

This is just one of a plethora of hands-on labs available for Silverlight. My favorite part about this one is that it truly covers at a medium level everything needed from front-end to back-end to get a full application working. I can make a generalization that there are 2 main parts to getting a Silverlight application up and running full-cycle:

1. The UI - which primarily consists of learning XAML. In no priority I can think of the following topics to learn:
   1. Customizing layout - using controls like Grid, StackPanel, and Canvas
   2. Styles - XAML has its own version of CSS. Styling has essentially become a "pattern", in which you separate your UI styling from the controls themselves and reference your style libraries
2. The Data - Data in Silverlight is tricky because the compact framework has nothing like ADO.NET, and good-luck finding an ORM framework that will work directly with Silverlight on the front-end. No, instead you really need to separate your data-layer (IMO a good thing). You have 2 main ways you can do this:
   1. WCF web services - This is how we retrieved data in this lab, and just as well you would update data through clearly defined API calls to your web-service
   2. Silverlight RIA services or O-Data - These options are for dealing with data as an ORM service. When you use O-Data, you now open your entire entity-model to your Silverlight application, a good or bad thing depending on your environment
      1. Shawn Wildermuth has a great blog post on Silverlight Data Access options

Full source code can be downloaded here.

Next Time
Likely not the very next post, but in the near future I intend to cover the Model-View-View Model design pattern

Contrarian Software Development asserts that some of the best known software development practices are really some of the worst, and that developers follow these practices just because they are best practices. The author has done a great job at summarizing the arguments against Unit Testing. Below are my responses to two of his posts on why "Unit Testing Sucks". I'm only repeating back his summary points so I recommend reading HIS posts before you read mine.

Take a Step Back
I'm having a hard time understanding why this is such a strong argument. Realize that this is an argument against testing in general. You can further abstract that this is really saying "Because A is not a silver bullet, we should not do A.".

The Counter-Argument
"True, but A does bring enough value to warrant the cost of doing A.". In other words, if A adds more value than cost, you should do A. In business people terms this is called a positive return on investment, or margin.

Back to Unit Testing
So coming back to Unit testing the question is not whether Unit testing can test everything. OBVIOUSLY it cannot, because there is no tangible definition for everything. The question is "Does the cost and effort of Unit testing warrant investing in it?"

Moving Forward
Let us stop shooting down a solution because it is not a silver bullet. Let's stop saying "You can't possibly test ALL permutations" or "It won't solve ALL of our problems" because WE KNOW THIS, and the proponents of such solutions NEVER make such claims (although they tend to sound like they do).

How do you Code Something to Work Correctly?
So I'm coding our payment processor. It needs to apply payments to invoices and update the customer's balance, and age the customer's balance correctly. This needs to be tested just as the quote says. So ...how do I know that I coded it correctly? I test it. Whether it's through formal Unit testing, or running informal scenarios, code needs to be tested.

Take a Step Back
All stuff that needs to work correctly needs to be tested. Whether it's a US Airways evacuation exercise, or a Toyota braking test, somebody somewhere somehow needs to do at least SOME level of testing.

Moving Forward
Let's stop debating whether something needs to be tested, and start debating on the best way to test it, or if you prefer "prove that that it works correctly".

Sidetrack - Programming Analysis
I took a course at the University of Texas called Analysis of Programs. This is one of those logic courses that despite its name we did not write a single program. One of the topics was something I'll call "Programming by Permutation". It's where you take all the inputs of your program (for example all parameters of a method) and iterate through all probable (not necessarily possible) combinations when testing your program for correctness.

Back to Unit Testing
Despite pejorative theory, the above is not as time consuming and wasteful as it seems. If you have a Unit Testing framework that supports Data-Driven tests than this is easy to accomplish. I'm not talking about all possible permutations here, just the practical stuff that you can think of. Following on my example earlier, I can't just test a payment applying to an invoice. I need to test if the payment is a reverse payment, if there IS no invoice, if the payment amount exceeds the invoice amount, etc. These are several unlikely yet possible permutations.

Take a Step Back
These are ALL improbable and yet possible production scenarios. Most IT shops do not test this and that's how they end up with "unanticipated combinations of user actions or circumstances". IT shops do not purposely avoid testing these scenarios by choice. It's because they feel that the time it would take to (Unit) test them is not worth the time it takes to deal with them when they happen (and they do happen) in production.

Moving Forward
So if the time it took to test scenarios, even the "unanticipated combinations" WAS minimal, then there's no reason NOT to test these. So whether the benefit is big, or the effort is small, either one of these makes testing worth it!

It Depends…
A LOT of developers shoot down this one. It really depends. But even generally speaking I don't agree with this. I think the most important part of the application is the user experience, which does include the interface but is NOT limited to it.

It's the Data Stupid
If you're planting a Zen-Garden , yes the interface is the most important. But on an accounting, billing, transaction processing, line-of-business, e-commerce, bulk-data, resource management, workflow-based, search-taxonomy, content management system, the data is just as important if not more.

Define "important"
I don't personally agree with this, but it's true. To most companies, money is important. Bad user interfaces cause frustration, but not loss of money (at least not directly). Bad data can cause SO many problems. It can cause lawsuits, which cost money. It can lower billing accuracy, customer satisfaction, transaction timeliness, etc. All of which cost money.

Moving Forward
Priority #1 is making your program work and work correctly. Making it look cool is unfortunately not a priority.

Arguing on the Subjective
I can't argue against this one, because it's an opinion. I can only vouch from experience. We introduced Unit testing at my job and got raving feedback. I'm paraphrasing but the #1 response I got was along the line of "I love that when I need to make a correction, I can just hit F5 (re-run) and watch the scenario play again!". I've had good experiences. Joe Contrarian has had bad experiences. We're technically at a stand-still .

It's all Relative
Setting up Unit tests might be boring and unfulfilling. But relatively speaking, what is more boring? Having to manually mock up scenarios EVERY time you work on code? Having to deal with the Production issues that result from not testing your code? Yes, testing can be more boring than running wild with new development. That's like saying going fishing is more fun than maintaining your fishing equipment.

Moving Forward
Testing and verification are necessary evils, and done wrong they can be time consuming. THAT is what Unit testing is about. Making testing easy, repeatable, and NOT time consuming, thereby allowing you to spend less time testing and more time developing. Sound like fun?

Blaming the Enforcer
"I hate speed limits. They cause me to drive slower than I can, and therefore I get there slower when I know I can get there faster" Unit Testing does force you to put more thought into encapsulation. It's true that if I didn't have to encapsulate, use good object-oriented programming practices, write Unit tests, or go through this "QA process", I could more quickly write a successful program. Except that it wouldn't be successful. The fact that Unit testing enforces good coding practices is not a flaw, but a fringe benefit!

Taking a Step Back
But he brings up a good point. If I'm working on a program that really doesn't warrant encapsulation, then that's most likely the type of program that doesn't warrant Unit testing either. these apps are often called "throw-away" applications.

Moving Forward
Unit testing is not a silver bullet or a golden hammer. Systems that don't need to be correct, throw-away apps, and systems that are ALL UI based do not need Unit testing. But the remaining 97% of systems out there DO warrant some form of formal testing.

What it means
If literature was bound by proper semantics, its potential would be limited. This is because literature is not about grammatical correct-ness. It is about elegance, beauty, and open interpretation. Grammar would in effect, ruin literature just as Unit testing would ruin good software.

The Flaw
Except that software MUST be bound. It is bound by logical correct-ness. When accounts receivable complains that their customer balances are screwed up because of buggy software, I can't approach them as a literary programming poet and convince them that there are multiple interpretations of correctness, because there are NOT.

A Better Analogy
Much like legal documentation, software must avoid room for interpretation. 1+1 must equal 2. There must be a clearly defined speed limit. There must be a classification for what constitutes a planet and that is why we have exactly nine eight planets in our solar system and no more or less.

This is the first in a series of research, analysis, and examples I've been working on. I went to Wikipedia to get an idea of "what the people" thought about Unit Testing, and I noticed that this debate is a never-ending one. For the record I'm an extreme proponent of Unit Testing. If I could change 2 things about the world, the 2nd would be to force all IT shops to adopt Unit Testing (The 1st being the elimination of poverty). Before I go any further let's be clear on what Unit Testing is. This is straight from Wikipedia:

My Thesis: The #1 reason IT shops don't Unit Test is because the value it adds is only obvious to developers (a.k.a. the people who don't control the schedule / budget). Beyond that the value to the business is not obvious, thus making the investment trivial.

The remainder of this post consists of excerpts from the same article mixed with my own commentary.

The Goal of Unit Testing

By isolating each part of a program and proving them correct, the result is that it finds problems early in development cycle

So by finding them early, you don't find them later. Finding them later is often more costly because:
 • It's likely already affected production data
 • You have to clean up after it AND re-create the scenario
 • Developers spend unplanned man-hours on fixing issues
 • Arguably the most crucial, your users / customers will have noticed it

Benefits

• The ROI (Return on Investment) is obscure to all but developers, and even then your team is likely to be in contention, not because they disagree per-say, but because it requires some discipline and coordination, and most development teams behave like dysfunctional families
• Your stakeholders aren't concerned with future change, they're concerned with accomplishing an immediate goal. And unless an IT manager is truly spearheading the project, there's no room on the schedule for regression.

Unit Testing Limitations

This time we'll use a WPF Application to showcase the difference between deleting in-memory objects and garbage collecting on memory. I have a basic ListBox container bound to a collection of my class: ByteContainer.
My CRUD operations allow me to allocate mega-bytes of data to my desire.
To the right is my command to perform garbage collection. This button executes the method GC.Collect().
Also notice the bottom-right is a dynamic snapshot of my total process memory, which will essentially be the value of PerfMon at any time.

The ByteContainer class is a very simple class which serves merely as a container around a byte array.

    namespace GarbageCollectionAnalysis.Surface
    {
        public class ByteContainer
        {
            private byte[] _data;

            public string Name { get; set; }

            /// <summary>
            /// Returns size in megabytes
            /// </summary>
            public int Size
            {
                get
                {
                    if (_data == null)
                        return 500;
                    return _data.Length / 1024 / 1024;
                }
            }

            public int DisplayLength
            {
                get
                {
                    // 150 is the max length of the rectangle
                    // 150 / 1000 = displaylength / size
                    return (int)((150D / 1000D) * Size);
                }
            }

            // max megabytes is 1000
            public void SetSizeInMegabytes(int size)
            {
                int sizeInBytes = size * 1024 * 1024;
                _data = new byte[sizeInBytes];
            }
        }

    }
    

I'll run 2 scenarios , the first of which I control the Garbage Collection

Scenario 1:
 • Allocate 500 MB
 • Allocate 200 MB
 • Allocate 300 MB
 • Delete the 500 MB and 300 MB blocks
 • Call Garbage Collection

Here are the results of Scenario I. Notice that when I deleted my memory blocks, in-process memory did NOT reduce until I called Garbage Collection

Scenario 2:
 • Allocate 500 MB
 • Allocate 500 MB
 • Delete 1000 MB
 • Allocate 100 MB 10 times in a row

Here are the results for Scenario 2. I didn't call Garbage Collection myself, but because the first 1000 MB was already deleted, Garbage Collection made room for my new data only when it needed to.

Here are the results for Scenario 2. I didn't call Garbage Collection myself, but because the first 1000 MB was already deleted, Garbage Collection made room for my new data only when it needed to.

Full source code can be found HERE