Quickduck

Many of the controls in ASP.Net (e.g. a Repeater) support the concept of an AlternatingItemTemplate, which, as the name suggests, allows you to define an additional item template to change the look and feel for each alternating item in the data source. This is all well and good, but I’ve never seen a good use for it; more often than not, all you really want to do in your alternating item is, for example, slightly change the background colour for ease of visual differentiation.

Though you can use the alternating item template for this, it typically involves you duplicating a lot of code, since the AlternatingItemTemplate is mostly the same as your ItemTemplate (save perhaps for a CSS class declaration somewhere).

  <asp:Repeater ID="rpt" runat="server">
      <HeaderTemplate>
          <table cellpadding="0" cellspacing="0">
              <tr>
                  <th>First Name</th>
                  <th>Last Name</th>
                  <th>Age</th>
              </tr>
       </HeaderTemplate>
       <ItemTemplate>
              <tr>
                  <td><%# Eval("FirstName") %></td>
                  <td><%# Eval("LastName") %></td>
                  <td><%# Eval("Age") %></td>
              </tr>
       </ItemTemplate>
       <AlternatingItemTemplate>
              <tr class="Alternating">
                  <td><%# Eval("FirstName") %></td>
                  <td><%# Eval("LastName") %></td>
                  <td><%# Eval("Age") %></td>
              </tr>
       </AlternatingItemTemplate>
       <FooterTemplate>
          </table>
       </FooterTemplate>
  </asp:Repeater>

If this sounds like you, then never fear - there IS a better way!

When you’re binding, you have access to the RepeaterItem via the Container property, which contains an ItemIndex property. As such, the simplest way of alternating your items is simply to check if the number divides evenly by two:

  <asp:Repeater ID="rpt" runat="server">
      <HeaderTemplate>
          <table cellpadding="0" cellspacing="0">
              <tr>
                  <th>First Name</th>
                  <th>Last Name</th>
                  <th>Age</th>
              </tr>
       </HeaderTemplate>
       <ItemTemplate>
              <tr class="<%# Container.ItemIndex % 2 == 0 ? "Alternating" : String.Empty %>">
                  <td><%# Eval("FirstName") %></td>
                  <td><%# Eval("LastName") %></td>
                  <td><%# Eval("Age") %></td>
              </tr>
       </ItemTemplate>
       <FooterTemplate>
          </table>
       </FooterTemplate>
  </asp:Repeater>

There is a minor downside using this approach - the non-alternating rows will all declare an empty CSS class within them. But, this is a sacrifice I think is acceptable to decrease repetition of code.

This is actually quite straightforward, but something that perhaps you may not have thought about.

On my current project, I have the concept of a “PerishableObject” - an object whose value is only valid between two particular dates. The interface for an IPerishable looks something like this:

public interface IPerishable {
    /// <summary>
    /// Get/Set the date that this component is valid from
    /// </summary>
    DateTime? ValidFrom { get; set; }

    /// <summary>
    /// Get/Set the date that this component is valid until
    /// </summary>
    DateTime? ValidTo { get; set; }
}

Now, logically, I wanted to create a helper method called “IsValidOn”, which could be passed a date, and would return true/false indicating if the component is valid on the supplied date. Obviously, I could define this in the interface, but that would leave me to either implement the method on every object which implements the interface, or to create a common base class which implemented that method, and then force all perishable objects to inherit from this base class. Both of these are not desirable!

Thankfully, extension methods in C# 3.0 provide a perfect solution for this:

/// <summary>
/// Determines if the perishable component is valid on the given reference date
/// </summary>
/// <param name="component">The component to be tested</param>
/// <param name="referenceDate">Reference date to test</param>
/// <returns><c>true</c> if the perishable component is valid on the given reference date</returns>
static internal bool IsValidOn(this IPerishable component, DateTime? referenceDate) {
    if (!referenceDate.HasValue) {
        return true;
    }

    return (!component.ValidFrom.HasValue || component.ValidFrom.Value <= referenceDate)
        && (!component.ValidTo.HasValue || component.ValidTo.Value >= referenceDate);
}

Defining extension methods against an interface is a great way of extending the interface without bulking it up.

It’s been a while since anyone has posted a daily question, but here’s one to get y’all in the mood…

Given the following code:

public class BaseClass {
    public BaseClass() : this("Base value") {
        Console.WriteLine("Base: Empty");
    }

    public BaseClass(object value) {
        Console.WriteLine("Base with value: {0}", value);
    }
}

public class DerivedClass : BaseClass {
    public DerivedClass() : this("Derived value") {
        Console.WriteLine("Derived: Empty");
    }

    public DerivedClass(object value) : base(value) {
        Console.WriteLine("Derived with value: {0}", value);
    }
}

What will be printed to the console when a new DerivedClass object is created using the default DerivedClass constructor:

    new DerivedClass();

First person to post the correct answer wins a prize consiting solely of that warm fuzzy feeling you get by being the first person to answer a question correctly.

I’ve been focusing a lot (read: “learning”) on WPF lately, and one thing that crops up all the time is StaticResource and DynamicResource. I had tried to infer their usage/differences from the context of where I’d seen them used, but I could never quite get it right. Anyway, I just read a nice definition which makes it all rather clear:

Static resources are resolved at compile time, whereas dynamic resources are resolved at runtime.

Use DynamicResources when the value of the resource could change during the lifetime of the Application.

Use StaticResources when it’s clear that you don’t need your resource re-evaluated when fetching it – static resources perform better than dynamic resources.

My latest contract has seen my development time focus strongly on Sql Server, Xml and C# server side code.

However, lately I’ve been playing around with all the new Asp.Net 3.5 extensions (MVC) and Linq with VS 2008 and found that I could use a refresher course in all things Javascript - particularly Ajax and JSON.

I found this awesome guide which gives you a quick reminder of the useful techniques required to author some top notch client side code when building web apps.

If you want to run sql server scripts through code, you can’t just run a standard ExecuteNonQuery() with a SqlCommand. There’s problems with ExecuteNonQuery() recognizing multiple sql statements.

Don’t fear though, if you reference the Microsoft.SqlServer.Smo and Microsoft.SqlServer.ConnectionInfo assemblies you get access to some goodies that’ll help you on your way!

using System.Configuration;
using System.Data;
using System.Data.SqlClient;

using Microsoft.SqlServer.Management.Common;
using Microsoft.SqlServer.Management.Smo;

SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["DBName"].ConnectionString);
Server server = new Server(new ServerConnection(connection));
server.ConnectionContext.ExecuteNonQuery(File.ReadAllText("SqlScript.sql"));

A classic problem to unit testing code that modifies the underlying data in the database tables is that you need to find a way to revert back to the original database state so that the tests can be run over and over again.

Using the transaction capabilities provided with the .Net 2.0 framework and a unit testing framework you can achieve this easily.

The process:

• Create a new transaction before each test.
• Dispose (Rollback) the transaction after each test.

    using System.Data;

    [TestClass]
    public class DataProviderTest {

        private readonly DataProvider _dp = new DataProvider();
        private TransactionScope _transactionScope;

        [TestInitialize]
        public void TestInitialize() {
            _transactionScope = new TransactionScope();
        }

        [TestCleanup]
        public void TestCleanup() {
            _transactionScope.Dispose();
        }

        [TestMethod]
        public void InsertTest()
        {
            // modify the database
            ...
        }
    }

It’s been a while since I’ve had the opportunity to catch up on what’s been happening in the Ent.Lib space.

I was pleasantly surprised to find two awesome new application blocks included in Ent.Lib 3.x versions:

• The Policy Injection App Block
• The Validation Application Block

The policy injection app block addresses Aspect Oriented programming concepts - the ability to affect code across systems using policies.

Check out a great introduction powerpoint show here.

The validation app block allows you to configure validation logic around members and methods.

You can find some details about the Validation App Block and all the latest Ent.Lib features here.

Recently I showed you how to pull sql query result sets into object instances using the XmlReader and deserialization. This article aims to show you the opposite process - persisting an object instance into a database table using serialization and Sql Server xml parsing.

The same Channel database table and entity class will be used for all examples.

/// Represents a media channel (e.g. web, mobile, iphone, etc.)
public class Channel    {
  private int _id;
  private string _type, _description;

  public Channel(){}

  public Channel(string type, string description)  {
    _type = type;
    _description = description;
  }

  /// Get/Set the channel identifier
  public int Id {
    get { return _id; }
    set { _id = value; }
  }

  /// Get/Set the channel type (e.g. web, mobile, iphone, etc.)
  public string Type {
    get { return _type; }
    set { _type = value; }
  }

  /// Get/Set the description of the channel.
  public string Description {
    get { return _description; }
    set { _description = value; }
  }
}

The Stored Procedure

The sproc takes in an sql server xml datatype parameter. This is provided via a normal string representation of the xml. Within the SPROC you prepare the document for querying, pull out the values you require and perform the insert.

To understand the following SPROC, you need to have have a basic understanding of:

a) how your object instance xml serialization format looks

<?xml version="1.0" encoding="utf-16"?>
<Channel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Id>0</Id>
  <Type>web</Type>
  <Description>800x600 or larger browsers</Description>
</Channel>'

and

b) an understanding of xpath and xquery for pulling the values out from the xml.

Check out the - Resources - Sql Xml - for some links that might help you out.

CREATE PROCEDURE [usp_PersistChannel]
	@xmldoc XML
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE
            @iDoc int,
            @type varchar(50),
            @description varchar(255)

    EXEC sp_xml_preparedocument
           @iDoc OUTPUT,
           @xmldoc,
            '‘

    SELECT
            @Type = [Type],
            @Description = [Description]
    FROM
            OPENXML (@iDoc, ‘/Channel’,3)
	WITH (  [Type] varchar(50) ‘./Type’,
	Description] varchar(255) ‘./Description’ )

    EXEC sp_xml_removedocument @idoc

    INSERT INTO Channel VALUES (@Type, @Description)                

    SELECT @@IDENTITY
END

Data Access Code

The following is a convenience method to help aid the serialization process of an object instance.

        /// Serialize an instance of an object to a string.
        public string Serialize(object instance)
        {
            StringBuilder sb = new StringBuilder();
            StringWriter sw = new StringWriter(sb);
            XmlSerializer serializer = new XmlSerializer(instance.GetType(), null, new Type[0], null, null);
            serializer.Serialize(sw, instance);
            return sb.ToString();
        }

Usage Examples:

        /// Persist a Channel.
        public void Persist(Channel channel)
        {
            channel.Id = Int32.Parse(
                                Database.ExecuteScalar(
                                   Database.GetStoredProcCommand("usp_PersistChannel", Serialize(channel))
                                ).ToString()
                             );
        }

The following article tries to outline an approach for unit/integration testing using the Visual Studio Team System testing framework.

The article is long, but hopefully worth the read.

Defining terminology

Unit Testing vs. Integration Testing vs. System Testing

The following is taken from our good friends at Wikipedia.

Unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application, in OO the smallest unit is a method; which may belong to a base/super class, abstract class or derived/child class.

Ideally, each test case is independent from the others; mock objects and test harnesses can be used to assist testing a module in isolation. Unit testing is typically done by developers and not by end-users.

Integration testing is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing.

Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

System testing of software is testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. [1]

As a rule, system testing takes, as its input, all of the “integrated” software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the “inter-assemblages” and also within the system as a whole.

Whitebox Testing (goes hand in hand with Unit Testing)

Unit Tests typically are usually written with intimate knowledge of the unit being tested – which allows all paths within the unit to be covered by the tests ensuring complete code coverage.

Mocking frameworks such as Rhino provided utilities to help assert code paths are tested.

For more information, see http://en.wikipedia.org/wiki/Whitebox_testing

Dependency Injection

Dependency injection aims to solve a particular problem in designing and constructing data structures dependent on other pieces of code, in a way that minimizes the coupling between them.

Dependency injection aids in helping to test particular units of code, substituting in your own versions of the dependency, removing the need to test the dependent code.

For more information, see
Dependency Injection & Testable Objects
Inversion of Control Containers and the Dependency Injection pattern

Mocking

Using the Dependency Injection pattern doesn’t require the use of a mocking framework to by-pass dependencies. It’s entirely plausible to create your own implementations and pass through. This however, will require a lot of time writing the code and cause your projects to bloat. A mocking framework should provide the facility to create dependency implementations (mocks) dynamically, taking the hard work away from the unit tester. The framework also, should provide functionality to help you assert that the mocked objects are used the way you expect them to behave.

There are various mocking frameworks out in the wild, I personally have used NMock and Rhino Mock. My experience with both favours Rhino Mock for flexibility, ease of use and performance. Type.Mock seems to get a lot of high praise too.

For more information, see:
Rhino Mocks - Introduction
Rhino Mocks - Documentation

Time for a Code Walkthrough

We have a CustomerServices class that provides business functions for a Customer entity. The CustomerServices class uses a CustomerDataAccess object to persist/read information from a database. Therefore, the CustomerServices class has a dependency on the CustomerDataAcess class.

A first cut of the two classes might look like this:

public class CustomerDataAccess : ICustomerDataAccess {

        public void InsertCustomer(string name)
        {
            // long running dependency
            Thread.Sleep(10000); // 10 seconds.
        }
}

public class CustomerServices {

  public void AddCustomer(Customer customer){
            new CustomerDataAccess().InsertCustomer(customer.Name);
  }

}

As you can see when we write a unit test for the CustomerServices.AddCustomer method it will make a call to the CustomerDataAccess class and take 100 seconds to complete.

[TestMethod]
public void TestAddCustomer () {

  Customer customer = new Customer();
  customer.Name = "Ben";

  new CustomerServices().AddCustomer(customer);

 // To verify the test worked, a database lookup would be required.

}

Now we should already have appropriate unit tests for the CustomerDataAccess.InsertCustomer() method, so in our CustomerServices tests we can remove this dependency as it has already been tested.

Let’s re-write the CustomerServices class to utilize the dependency injection pattern:

public class CustomerServices {
        private readonly ICustomerDataAccess _customerDataAccess;
        public CustomerServices() : this (new CustomerDataAccess()) {}

        // using internal prevents the constructor from being publicly
        // available to other assemblies.
        internal CustomerServices(ICustomerDataAccess customerDataAccess)
        {
            _customerDataAccess = customerDataAccess;
        }

        public void AddCustomer(Customer customer) {
             _customerDataAccess.InsertCustomer(customer.Name);
        }
}

NOTE: To allow our unit testing project to access the internal members of the project we’re testing, an attribute is added to the AssemblyInfo.cs file.

#if DEBUG
  [assembly: InternalsVisibleTo("CustomerServiceTests ")]
#endif

Now we have the ability to insert our own CustomerDataAccess object, we’ll create our own mock object and use it to remove the dependency – this is for illustration purposes only.

public class MockCustomerDataAccess : ICustomerDataAccess {

      private int _insertCustomerCount = 0;

      public void InsertCustomer(string name) {
            _insertCustomerCount++;
      }

      public int InsertCustomerCount {
            get { return _insertCustomerCount; }
      }
}

[TestMethod]
public void TestAddCustomerWithStaticMock() {
      Customer customer = new Customer();
      customer.Name = "Ben";

      ICustomerDataAccess mock = new MockCustomerDataAccess();

      CustomerServices _customerServices = new CustomerServices(mock);
      _customerServices.AddCustomer(customer);

      Assert.AreEqual(1, mock.InsertCustomerCount);
}

As you can see here, creating our own mocks and keeping metrics will become tiresome and mean code bloat – especially as you might need many instances of the same interface for differing code paths etc.

Don’t worry though there is a way forward – using a mocking framework like Rhino Mocks.

[TestMethod]
public void TestAddCustomerWithDynamicMock() {
      // create the Rhino mock repository
     _mockRepository = new MockRepository();

      // get a dynamic instance of the ICustomerDataAccess interface
      _dynamicMock = (ICustomerDataAccess) _mockRepository.DynamicMock(typeof(ICustomerDataAccess));
      _customerServices = new CustomerServices(_dynamicMock);

      // Expect the CustomerDataAccess.InsertCustomer method to be called exactly once.
     _dynamicMock.InsertCustomer(null);

      LastCall.IgnoreArguments().Repeat.Once();
      _mockRepository.ReplayAll();

      Customer customer = new Customer();
      customer.Name = "Ben";
      _customerServices.AddCustomer(customer);

      // ensure the asserts are correct
      _mockRepository.VerifyAll();
}

Using Rhino Mocks we don’t need to create hard-coded mock objects for our tests and we get built in metric checking and a whole lot more – all for free.

What to Test?

1. Any non-trivial piece of code.
2. All code is non-trivial.
3. Then again, something’s just aren’t worth your time.
4. Confused?

For every method that has some meat on it, there should be [TestMethod]s that test all execution paths.
Public properties that are just get/set would be a situation of overkill.

The VSTS code coverage tool is excellent for seeing what you’ve tested and what’s been missed.

To use the VSTS code coverage tool, open up VS 2005 and edit the selected test configuration run:

Click for Full Size Image

Then select the assemblies you wish to monitor:

Then all you have to do is run your tests (but not in debug mode) for it to calculate the metrics. Once finished open up the Code Coverage Window and inspect the results.

Click for Full Size Image

What about Integration Testing?

We can still use the VSTS unit testing framework to write integration tests. The difference though, comes from the point of view that the test methods will not substitute in mocks for the dependencies, allowing the tests to run end-to-end testing a module/function of code right through.