ThoughtShapes Shaping Ideas With Thought

What is good practice for understanding a system? What is the point of understanding a system? How and when does that understanding become outdated? These questions are relevant to system documentation - our topic. This article seeks to directly answer each of these in turn.

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:

...is always the most special, no? Hmmm...I guess I would say "no" to that and chalk it up as another cliche that might be true for some but hopefully not for most.

Anyway, after countless deliberations and requests we've finally got a blog up and running. Thanks to Rjae for giving me the prod I needed (Rjae doesn't actually prod, he just does, and if you're paying attention it's the perfect stimulus).

Later.