First, to maximize the benefit of unit testing, let's make a clear (and industry standard) delineation between unit and integration testing:

• Unit test are in isolation from external resources, e.g. files, databases, web services; in SQL, it might be isolation from foreign keys.
• Integration tests utilize these resources.

One benefit of this distinction is that external resources may cause errors that have nothing to do with your code, which therefore would be false alarms. Another benefit is speed - the isolated unit tests will run much faster than the integration tests, giving you feedback that much more quickly. Slow tests will just frustrate you as you sit around waiting for them to complete, and you'll be less likely to run them frequently.

Thus it is best to put these into separate test projects. Run all of the unit tests very frequently, and run the integration test as often as is reasonable. The same principle applies to any automated UI or performance tests.

Project Setup

Each class should have its own test file, and each namespace its own folder - just as you would do for non-test code. If a class has many methods, or some methods require many different tests, it may be helpful to create multiple test files for a class. For example, you might have "MyClassTest_MethodA.cs" and "MyClassTest_MethodB.cs".

Helper Classes

It is often useful to put some code into a static class for re-use across multiple tests. For example, if you use Guids frequently, then create a static Guid variable that can be re-used everywhere:

public class Helper
{
    public static Guid GuidOne = new Guid("dd28ce17-218f-42cc-a023-caaf455cdfc5");
}

I've also used my Helper classes to build an object with other constant values, where that same object will be used in many different tests.

public const string TestPattern = "^[^ ]+";
public const string TestValue = "as df";

public static RegExTest BuildStandardTest()
{
    return new RegExTest()
    {
        Pattern = TestPattern,
        TestString = TestValue
    };
}

Test Template

The basic art of testing is to know your inputs and your expected outputs. At the code level this applies to methods / procedures; at the system level it applies to the application; and to the user, it typically applies to particular UI screens. Between these two sit the system under test. For a proper unit test, the system must be isolated before it is called. Finally, you must validate the output.

1. Prepare input
2. Isolate the system under test
3. Call the system
4. Evaluate output

Just as with regular code, test code should be well structured. As non-production code, it might be more forgivable to take a few shortcuts; still, comments should not be omitted. I like to put these four steps into the comments. The name of the test should clearly indicate its purpose. If there are multiple code paths to test for a single method, it might be challenging to come up with meaningful names for each. Method level comments should clearly describe, in plain English, the purpose of the test. To be a real stickler about traceability, the method-level comments might mention a user story to which the test applies.

Example from my Reggie project (more about Moles in a separate article):

/// <summary>
/// A test for the TryIt method.
/// </summary>
[TestMethod()]
[HostType("Moles")]
public void t_TryIt()
{
    // Prepare input and expected values
    string pattern = "pattern";
    string testString = "testString";
    string expected = "anything will do";

    // Mockup the RegExTest class
    bool tryPatternWasRun = false;
    Reggie.BLL.Entities.Moles.MRegExTest.AllInstances.TryPatternMatch = (RegExTest iTester) =>
        {
            tryPatternWasRun = true;
            Assert.AreEqual(testString, iTester.TestString, "wrong TestString");
            Assert.AreEqual(pattern, iTester.Pattern, "wrong Pattern");
            return expected;
        };

    // Run the system under test
    string actual = ExpressionTest.TryIt(pattern, testString);

    // Validate results
    Assert.AreEqual(expected, actual, "Wrong output");
    Assert.IsTrue(tryPatternWasRun, "TryPattern wasn't run");
}

In some cases isolation may not be required; in this particular case, I knew that TryIt would be calling method TryPattern, and I bypassed it. Since TryPattern doesn't call any external resources, I didn't have to code it this way. But by doing so, I completely isolated the TryIt method from everything else.

The validation portion could be skipped in some cases; for example, if you expect an exception to be thrown, many languages will let you specify an "expected exception" rather than having to catch the exception and test its type. For example:

/// <summary>
/// A test for TryIt with null Pattern input.
/// </summary>
[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void t_TryIt_NullPattern()
{
    // Prepare input and expected values
    string pattern = null;
    string testString = "testString";

    // Run the system under test
    ExpressionTest.TryIt(pattern, testString);
}

There are many tools and methods available to help software developers today. Brooks himself refers to the power of object orientation, inheritance and polymorphism for enabling reuse. Refactoring, combined with a complete set of automated unit tests, should significantly reduce the up-front cost of developing for reusability. Language features such as Generics and Anonymous Delegate allow for a great deal of flexibility in reusable code.

Static code analysis tools can help spot common flaws in security, design, naming, and more – thereby helping to improve not only the maintainability but also the discovery of functionality. For the .Net developer, Pex's automatic discovery of unhandled exceptions can do much to improve, quickly, the code hardening efforts.

XML code comments, which can be enforced in static analysis, are quite helpful in explaining the purpose of a class and its methods. Brooks mentions the importance of code samples, beyond general documentation, for explaining complex reusable code. These can be embedded in the Remarks section of an XML comment. For the .Net developer, these comments can be compiled into web pages using Sandcastle. Load these pages into IIS. Perhaps configure a search engine. Take a suggestion from Brooks by publishing a weekly summary of the new/updated documentation.

FFor all that, the human touch is probably the most potent approach; peer review and pair programming provide ample opportunity for sharing about available components and modules.

With all these advantages today, the only excuse for not building your code to be reusable is that you know it won't be reused. In that case, don't waste your time. Refactor later if you were wrong.

It is not sufficient, Brooks posits, to expect changing requirements and hope for the best. Thus he goes on to advocate that the software development group be organized for success in a changing environment. But he also makes the assertion that software needs more control, not less, which on the surface seems to be a call for a strict waterfall. He doesn't want tentative plans.

One of the signs of true genius is recognizing new data, accepting that a former conclusion might be wrong, and moving forward with the new premise. In new chapter "The Mythical Man-Month after 20 Years," Brooks accepts that "[t]he biggest mistake in the "Build one to throw away" concept is that it implicitly assumes the classical sequential or waterfall model of software construction." Thus in 1995 his vision of software development was updated to include the reality of incremental and iterative design. His 1986 paper, "No Silver Bullet" (ch 16) actually spelled out the need to "[utilize] rapid prototyping" and "[grow] software organically." A common misconception about Agile development is that it is uncontrolled. In the context of the whole, Brooks is calling for careful governance without the stultifying commitment to tollgates and a single-pass design that are called for by waterfall.

"One useful mechanism is a telephone log kept by the architect. In it he records every question and every answer. Each week the logs of the several architects are concatenated, reproduced, and distributed to the users and implementers. While this mechanism is quite informal, it is both quick and comprehensive." (p69)

One-line e-mail: "Did you look in the Wiki?"

One can imagine a much snarkier-sounding e-mail coming from a frustrated developer who does not want to be interrupted with "trivialities." But that's an unfortunate attitude, one that fails to recognize the importance of respect and service to other group/team members, without whom the developer's job might be meaningless. Perhaps a better response would be:

"Yes, I had a difficult time understanding that as well. We've documented that in the Wiki; please click under XXXXXX and then find the link with YYYYY in it."

Better yet, if time permits: copy and paste from the Wiki into an e-mail, and include the Wiki link for future reference. This is, of course, a double-edged sword. Somehow, someway, "users and implementers" must be encouraged to read the documentation for themselves, and discouraged from asking a thousand questions that have already been answered.

I do not recall that Brooks's sagacity encompassed this area. The best that I've come up with is this: offer to schedule an hour with the individual later in the day/week, and ask the individual to hold all but the most critical questions until that time. This gives the person an opportunity to find their own answers, allows you to continue focusing on your current efforts, and the face-to-face time may even be more appreciated than the individual responses would have been.

I have mixed feelings about this book. I've spent several years working diligently on my flow-charting capabilities, using what scan resources I could easily and quickly sift through on the Web and in the Visio Help, studying the charts in all the comp-sci books I've read, and garnering feedback from my colleagues. This book might have sped up that process significantly, and has already had a positive impact on the communication efficacy of my charts. But, I simply didn't completely like the specific modeling "language" presented by the authors.

The second half of the book moves beyond mechanics, and it is the more powerful portion. For it is there that we dive in to application, learning how the authors think and approach problems (most of which are in the domain of computing, but allusions are made to uses for other industries). The second half is also home to rare and valuable discussions of style, consistency, and simple communication. I suspect I shall return to the second half many times in coming years, looking for tips and reminders that will further improve the architectural models I build.

Recommended for: system architecture modeling and business analysis. Not recommended for: application design modeling. Even the authors agree that you should stick with UML for design of particular applications.