Ideally, SQL queries are executed really fast (sub-second). However there are times when it takes many seconds, even many minutes to execute each step. We have traditionally used the PRINT statement in SQL to output trace type information to the console so we can see what's happening.

Recently I noticed that the PRINT statement output wasn't coming out when I expected it should. In doing some research on the issue, I discovered that the PRINT statement output is queued and batched rather than real-time.

The solution for this problem is to use the RAISEERROR statement instead. Here is an example:

DECLARE @msg NVARCHAR(MAX) = 'status message'
RAISERROR (@msg, 0, 1) WITH NOWAIT

The severity of 0 tells SQL that everything is still fine, and NOWAIT instruction tells SQL not to queue it but to output immediately. The 1 is a locator that can be used to tell someone where to find the source of a particular message, if they are kept unique throughout the code.

So, for long-running queries, use RAISEERROR and get those status messages out in real-time!

OK people. STOP putting cowboy code on my desk. Seriously. TEST your software. REALLY. Please STOP writing BRAND NEW LEGACY code.
< /Rant >

OK I feel better. But not really. Just because a system is not considered to be a "production release" (meaning that people outside the particular organization or business won't have access to it) it DOES NOT mean that we can cowboy it up and plop a steaming pile of untested code out there for our colleagues or coworkers to consume.

ALL CODE NEEDS TESTS. Period.

Untested code is NOT finished. Please don't just assume that if the code "works" that it's ready to inflict on other people (or even yourself). Self-inflicted legacy code casualties are the second highest cause of career paralysis, according to 4 out of 5 dentists. By definition, code is "legacy" if it doesn't have tests.

Here's a plan to get your tests caught up.

Start Small
At least we need a set of "sanity" checks... if nothing else. Create a "test suite." Use xUnit or the like, keep it simple. Start with the checks for the obvious output... if that doesn't show up, then something is clearly broken.

Add Some More
One at a time if you have to, add another test for something. Any kind of test will do... unit, functional, acceptance... I recommend starting with acceptance and working backward. We already blew the op to be able to do TDD and get unit testing done, so now let's just make sure the surface behavior is adequate. Definitely do go in deeper if time permits.

New Feature
Each time a new feature is added, update the test suite to make sure everything is happy with changes that ripple out from the effect of the feature. Again - at least make sure that the obvious functionality is tested on the new code. Don't slack on it, keep at least the new code from being legacy.

Lather, Rinse, Repeat
Pick a time each week (say 4:30PM on Wednesdays) to put in a half-hour on writing one new test. Schedule it. Block the time out on your calendar so someone can't schedule a meeting... And hide if you have to - to avoid distractions.

What to Write
Focus on happy-path code tests only if there are none for that feature. Otherwise, do alternate and failure path tests, so that the behavior of the system is understood in circumstances other than the best-case. 90% of bugs occur in the not-happy path.

Using this strategy will get testing started, and contribute to a more robust and reliable product, no matter what it is. Remember that most "side projects" or "utilities" that are developed in-house will be used by your own people. We want them to have the best.

"But it's just a spreadsheet." OK, yes it is. I say we need to make sure to test even the lowly spreadsheet. Because, next week someone in Finance is going to discover it and begin to use it for their payroll planning... if there is a critical flaw in it, it might be YOUR paycheck that gets eliminated!

We should realize that even internal tools and web sites are usually used to make business decisions of some kind. We want to make sure that they are made using reliable tools, to the extent possible. Business relies on its data, now more than ever. Competition is fierce in a down economy - even small mistakes can be a big problem.

"Bread's not done until it's baked" - and neither is code! SO PLEASE: Test it. Bake it. Slice it... and don't get burned!

Here is a presentation I wrote to explain why Continuous Integration is important, and touch on some of the philosophy of how we think of CI. There are a lot of tools and techniques for CI however I did not go into specifically in this presentation. Scenario Examples may be available in the future as scripts for specific tools to build software with CI. If you want to see these, please reply and let me know.

PowerPoint version:

AgileDeveloperSeries-ContinuousIntegration.pptx (79.86 KB)

PDF version:
AgileDeveloperSeries-ContinuousIntegration.pdf (650.31 KB)

What makes a successful Agile developer? How are Agile developers different from regular developers? Here is a short presentation and video on the topic.

Video (xvid) 40MB

Presentation (PDF) 430KB

I recently recorded a tutorial video of a presentation I am working on. The video is intended to be an introduction to TDD, and how actually to go about writing tests and code using TDD. I hear a lot of people using the term "TDD" without really understanding it. They typically are referring to "unit testing" or sometimes even test-first development, neither of which are really TDD. So my thought was to show it actually being done.

It is my first attempt ever to record a video presentation, and there is some kind of hum on the audio I couldn't get rid of - sorry. I was able to convert it to a down-res format (quick-time), using the HandBrake converter tool. Hopefully it's still readable. This is unscripted and off-the-cuff, so I am sure there's lots of room for improvement. If you have suggestions, please feel free to post a comment below. Otherwise, enjoy!

Writing Unit Tests Using Test-Driven Development Apple QuickTime format, 65MB, 28 min.

"We need to do TDD" said the client.
"Our team is not producing quality code, and aren't performing up to our expectations."
"So, we need to introduce TDD to make sure we get what we need."

Uh-huh I thought. Thinking to myself... so, why aren't your developers producing quality code? What are they doing instead? Are they even unit testing at all now? Do they know how to test or are unit tests just an afterthought? oh yeah, and are there any other methodologies you need to add for your team to be buzzword-compliant!?

TDD is not just a buzzword. TDD is not just a methodology a team can adopt if they are in trouble. Not hardly. TDD is the top of the pyramid. It requires a mind-shift that is not tremendously difficult, but at the same time is very difficult to accomplish without discipline. Not every team is ready for this step. I would hope to have a cohesive, collaborative, and performant team, teach them how to write good tests (first or last), show them how acceptance criteria can be automated into tests that guide the team toward completion. After going through all of these pieces, I would then introduce TDD as a small thing, and the discipline required would probably already be there at that point.

While it may be in vogue to say a team is "agile" and uses "tdd" (note: here in lower case) it's much more important that a team is producing quality software - buzzwords or not. I am not exactly advocating non-tdd practices, but on the other hand we need to be practical about delivery also. If a team can truly do test-driven development, then congratulations I say, they are well positioned to be at the top of the heap. If not, I would try to lead the team in the direction to be ready for TDD, whether or not it gets used. Strong unit testing along with other kinds of testing will deliver the quality that customers need. So, evolve. Learn, Test well. And, if you can, use TDD.. it's great!

"TDD makes code development take longer."
Yes, it does. 15-30% longer.

"TDD *may* reduce bug counts..."
Real TDD WILL reduce bug counts. Expect about an order of magnitude. 60-90% comparably.

"I don't want to pay up front for testing or make the code take longer to be feature complete."
That is one choice - but it will be a costly one... Defects will not only be more frequent, but they will probably take longer to fix and be more complex as well.

From a financial perspective, (aside from the customer satisfaction) TDD just makes fiscal sense. I think we would need a compelling reason to give management and shareholders why we are NOT using it.

There is a new video posted on Channel 9 of an interview of one of the Microsoft researchers who contributed to a set of case studies published earlier this year. The case studies were done on 4 teams (3 Microsoft and 1 IBM), and they seem to agree with the statistics and team performance numbers I have been citing for years.

These numbers are motivators for me, and some of the primary reasons I practice TDD, support it, and try to spread the word.

Please take a look at the report and see for yourself if you agree...