ThoughtShapes Shaping Ideas With Thought

I can't think of a better way to learn how a complex application scenario truly works than to look at the test for that scenario (and the tests for related scenarios). What would you rather have:

1. A wordy document that is difficult to understand even if written by a solid writer?
2. A test that creates the complex scenario and tests the expected behavior?

The timing seems right to demonstrate a pattern for testing asynchronous processing. This follows up on Steve's assertion: Don't make assumptions, write the test.

For purposes of demonstration our user story will be: As a program I want to output a message after an event is raised. So let us start by writing a test. Our story implies an event reader and a writer. So let us use the runtime execution provided by test runner and make that the reader. The writer will be some other simple class.

Here's a snapshot of my VStudio environment with Resharper's UnitTestRunner window open. Although I'm not a big fan of pride, Rjae and I are admittedley quite proud of our test count right now, especially considering how early in development we are...

Believe nothing just because a so-called wise person said it. Believe nothing just because a belief is generally held. Believe nothing just because it is said in ancient books. Believe nothing just because it is said to be of divine origin. Believe nothing just because someone else believes it. Believe only what you yourself test and judge to be true.

~Buddha

Over recent years I've purposefully heightened my awareness to a condition in the software industry that I'll dub, "Assumptionitis." This usually occurs in a situation similar to the following:

If you're like me and you believe the tests serve as the documentation, I've noticed the following naming conventions help further this concept:

NCover is a tool that analyzes running code and is able to determine whether code was visited or unvisited while running. Visited code is code that was executed during the running of a process, and unvisited code is code that was not executed.

NCoverExplorer is a tool that does a great job of displaying NCover's test coverage XML output so that you can quickly make sense of it and put it to good use. To take you through an example, let's imagine I have a struct called PersonName in a C# project called Domain:

Man, this is a particularly sensitive topic to me, I must admit. That's mostly because "you must comment all your code" is usually a directive that comes from one of three kinds of people--each non-exclusive of the other:

You can download NCover using the links provided on the left. Once you have it downloaded, you install it (it comes as an msi file, even though I doubt it really needs anything but an xcopy deployment).

Now that we've taken a look at how to run NCover from the command-line and how to use NCoverExplorer to view NCover's output, we can take a look at the features in NCoverExplorer that allow you to do everything right from within its user-interface. If you click on the "Run NCover" button (the fifth from the left on the NCoverExplorer interface), you'll see this window: