http://www.npr.org/templates/story/story.php?storyId=89324244

http://www.npr.org/templates/story/story.php?storyId=6203264

http://www.npr.org/templates/story/story.php?storyId=89326007

I also put the additional spending plan worksheets on the public Google Docs site linked at:

https://docs.google.com/leaf?id=0BzrVGxp4EDFCZTIyY2E4Y2QtYjE5OS00YmMxLWJmN2ItOTAxNzU0OTMzZTlk&hl=en

Leave a comment if you like the documents.

Here is the link to the tools discussed in lesson 8.

https://docs.google.com/leaf?id=0BzrVGxp4EDFCZTIyY2E4Y2QtYjE5OS00YmMxLWJmN2ItOTAxNzU0OTMzZTlk&hl=en

Some additional management links you may find usefull:

www.passpack.com Secure site for storing passwords.

www.mint.com Financial aggregation tool.

www.AnnualCreditReport.com or 877-322-8228 FTC Approved free annual credit report.

As an example of what should and should not be tested I built a small demo application using Win Forms, ADO.Net, and the MVP pattern. My purpose in using the MVP pattern was to illustrate how forms are inherently difficult to test. While this example demonstrated greater testability and adherence to the guideline of never testing the database, an explanation of how the MVP pattern worked absorbed more time then I anticipated. So as a review I thought I would reiterate here the process of refactoring an untestable piece of ADO.Net code to make it testable.

The application has an MVP triad for viewing stock items; the components of the triad include a StockItemPresenter, an IStockItemPresenter interface, an IStockItemCallbacks interface, an IStockItemView interface, and a StockItemView user control. In answer to the question, “What the heck! What’s with all the interfaces?” the implementation of my MVP demo is based on the Separated Interface design pattern. Briefly this allows me to have my presenters in one project, views in another, and no circular references between the two. A brief description of each component follows:

• StockItemPresenter – concrete implementation of the IStockItemPresenter and IstockItemCallbacks residing in the Presenters project; all logic with regards to accessing and processing of stock items is performed within this class.
• IStockItemPresenter – the contract provided to the User Interface project that allows instantiation and access to the StockItemPresenter’s logic.
• IStockItemCallbacks – the contract provided to the view that allows communication of user actions back to the presenter.
• IStockItemView – the contract provided to the presenter by which data is supplied to the view.
• StockItemView – a user control inheriting from IStockItemView known as the “view” where data is displayed and users can initiate action.

Here is the scenario: My presenter implements the public method GetData() exposed by the IStockItemPresenter, with the following code.

public void GetData()
{
string connectionString = ConfigurationManager.ConnectionStrings["Demo1"].ConnectionString;
string selectString = “Select * from Demo.StockItem”;
SqlConnection connection = new SqlConnection(connectionString);
SqlCommand command = new SqlCommand(selectString, connection);
SQLDataAdapter result = new SqlDataAdapter(command);

StockItems items = new StockItems();
items.EnforceConstraints = false;adapter.Fill(items);

_view.StockItems = items;
}

This code is perfectly legal and is very commonly used when dealing with ADO objects in a Data Access Layer. So, what you may ask, makes this code untestable? It is an issue of control with the method’s collaborators. Here the method has control and is creating local variables that can not be alter from outside the method. When any unit test is run against this method the collaborators will act in their normal manner and attempt to connect through the SqlConnection and SQLDataAdapter directly to the database. That violates the guideline of never testing the database, which is an entirely different topic.

So, what can be done to make this code testable and better at the same time? What we need to be able to do is control the methods collaborators from outside of the method. Once the method’s collaborators can be controlled, they can be replaced with a fake. The faked collaborator can take the form of a stub or a mock, the complexity of the type will determine which to use. For the purpose of this discussion we will use a mock. A mock is a dynamic representation or proxy of an object, not the actual object itself. Interfaces are good candidates for mocking, but this code doesn’t contain any. As it turns out though, the SQLDataAdapter implements the IDataAdapter interface. That means if the method can be changed to use an IDataAdapter, and if we can control the instance of the IDataAdapter, then we can provide the method a fake. So, let’s refactor the code to use the IDataAdapter interface:

public class StockItemPresenter : IStockItemPresenter, IStockItemCallbacks
{

private IDataAdapterFactory _adapterFactory;
private IStockItemView _view;

public StockItemPresenter(IDataAdapterFactory adapterFactory)
{
_adapterfactory = adapterFactory;
}

public void GetData()
{
IDataAdapter adapter = _adapterFactory.GetAdapter(selectString);

StockItems items = new StockItems();
items.EnforceConstraints = false;
adapter.Fill(items);

_view.StockItems = items;
}
}

Several points about this refactoring need to be explained. The first is that we have now introduced a new object called an IDataAdapterFactory. The responsibility of this object to provide an abstraction of the creation of SQLDataAdapters. Using the Dependency Injection pattern we can feed the IDataAdapterFactory into the presenter when it is instantiated. This approach allows the mocking of the IDataAdapterFactory in the unit test and injecting the mock into the presenter. The next point is the inclusion of the IDataAdapter in the GetData() method. Under normal usage a true SQLDataAdapter would be returned by the IDataAdapterFactory, but in our unit test the factory can be instructed to return a mocked IDataAdapter, thereby allowing the unit test to make a call against the adapter adapter.Fill(items) without involving the database.

As a result of this simple refactoring our code is now fully testable, and arguably simpler. By inverting control of the GetData() method’s collaborators the unit test can fully validate the behavior of the method without reaching beyond it’s boundaries. We also removed redundancy from the codebase as all usage of SQL types are located in the adapter factory. And, in my estimation, the GetData() method more readable and intent revealing.

The demo application is available at UnitTest-1.ZIP. The zip file contains the demo application, a backup of the database, and a copy of my presentation slides. In the sample code I demonstrate the before and after code and how to perform the mocking with Rhino mocks. I hope this clears up some of the questions that were left in the presentation.

A simple statement about myself would include that I am a senior software developer currently working for XClaim Software. We are located in upstate New York and we develop solutions for the Insurance Industry. As a development group we have embraced the agile manifesto and endeavor to practice the spirit of agile development in our day-to-day efforts. Like many of my peers I came to .Net development from the world of VB, and have been continuously pleased by the rich development experience found in an object oriented environment.

A less simple statement about myself would state that I am a husband, father of two grown children, active in my church, and an avid cyclist. A cyclist of both the self propelled and the highly motorized versions. I don’t race, but I do ride my bicycle in fund raisers ranging from 100 to 300 miles.

So, my hope is that I can contribute information and ideas that some my find valuable.