TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling

Recently, I started a new position with a company transitioning to TDD. One of the things I'm trying to accomplish in my new job is to help my colleagues become effective in TDD without most of the growing pains I experienced. So in an effort to help my new organization, I'm using this blog to communicate all the things I wish someone had shown me before I started writing code with Test Driven Development. So, in a couple of parts, here is all the off-the-cuff advice I can think to give to a TDD newbie to avoid seeing NUnit red bars in their sleep and getting the “Shame Card” permanently affixed to their monitor (for repeatedly breaking the build).
Separation of Concerns

Separation of Concerns is one of the most important concepts in programming, and the single most effective strategy for writing classes and methods that are easy to test. Simply put, divide your system into modules or layers, each with a distinct area of responsibility. We’ve known that layering is a good idea for a long time, but nothing exposes an intermingled ball of mud than trying to write automated tests. After you do TDD for awhile, you will probably notice that you slice classes thinner than before.

At the heart of every programming paradigm and design technique is a “Divide and Conquer” strategy to break a complicated whole into easily digestible pieces. Using OO programming, we are mostly concerned with defining the different responsibilities of the code, and assigning the responsibilities to the logical classes and methods.

There are a couple of qualities (more info here) to guide the division of labor in your class structure:
Cohesion – A measure of whether a class has a well defined, meaningful responsibility. High cohesion is desirable. If a class contains unrelated functions or responsibilities, it is not cohesive.
Coupling – More or less, how entangled or dependent a class is with other classes. A loosely coupled design implies that classes or subsystems can largely be modified independently of one another. The Pragmatic Programmers call this quality “orthogonality.”

TDD is all about rapidly making small pieces of code work, then molding the pieces into the aggregate. Cohesion is important to us, because we want to focus on making a single concern work at a time. Coupling is important because we want to make a concern work without interference from other concerns polluting our tests. Data access, business logic, user interface display, messaging, and logging are examples of separate concerns or responsibilities that should be built and unit tested separately. Divide and conquer.

Here’s a sample of code that flunks both cohesion and coupling tests.

public void PublishBigThings()
{
    // Go get some configurion
    int threshold = int.Parse(ConfigurationSettings.AppSettings["threshold"]);
    string connectionString = ConfigurationSettings.AppSettings["connectionString"];
    
    string sql = select * from things where ready_to_publish = true and size > ";
    sql += threshold;
    
    SqlConnection connection = new SqlConnection(connectionString);
    
    connection.Open();
    SqlCommand command = new SqlCommand(sql, connection);
    SqlDataReader reader = command.ExecuteReader();
    
    while (reader.Read())
    {
        string name = reader["Name"].ToString();
        string destination = reader["destination"].ToString();
        
        if (this.IsDestinationApproved(destination))
        {
            Publish(name, destination);
        }
    }
}

The method is not cohesive because it is responsible for doing everything – pulling flags out of configuration, fetching data from a database, and making business logic decisions. The method is tightly coupled because it cannot function correctly without the proper configuration in place and a Sql Server database (other database engines need not apply).

“One Class, One Responsibility” is a good rule of thumb to follow in class construction. Don’t hesitate to create more classes. It can feel like more complexity, but it can also isolate complexities. See Fear of Adding Classes. It’s also much easier to make mistakes in big methods than in smaller methods.

More to come. Someday.