ScottD's Musings : Automated Unit Testing & TDD

Visual Studio 2005 Code Snippets for NUnit Developers!

Scott Dockendorf — Mon, 06 Mar 2006 12:51:00 GMT

Oh this rocks - wanted to share with everyone else.

Scott Bellware, TDD stud, Microsoft C# MVP, and active community member, created some awesome code snippets for developers interested in writing NUnit test classes.

http://codebetter.com/blogs/scott.bellware/archive/2006/02/28/139446.aspx

MSDN Article Published - Team System Automated Unit Testing & Code Generation

Scott Dockendorf — Sat, 19 Nov 2005 22:15:00 GMT

Yes, I have been a blog-slacker for quite some time now - and I apologize. We're closing down on a huge project at work, and I should pickup my activities in the coming weeks.

Shameless plug alert…

Thanks to Rob Caron, who pointed out that a number of Team System-related articles were published to MSDN Online, including one of mine titled:

Unit Testing and Generating Source Code for Unit Test Frameworks Using Visual Studio 2005 Team System

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/UTFwVS05TmSys.asp

This article covers an introduction to automated unit testing, and provides an insight into setting up a new Unit Test project, and what code is automatically generated for you.

Automated Unit Testing for the BizTalk Developer!

Scott Dockendorf — Sun, 17 Jul 2005 13:54:00 GMT

Thought this was very cool, and wanted to share.

Check out Kevin B. Smith's post on BizUnit 2.0, an automated unit testing framework for BizTalk solutions! His post offers a link to download the binaries, great detail on the framework, how it works.

Does anyone have experience with BizUnit 1 or 2?

VSTS Unit Testing & Microsoft AntiSpyware Beta

Scott Dockendorf — Mon, 09 May 2005 11:21:00 GMT

Thanks to Dave Bost AGAIN, for saving us developers precious time. :) First he published a GREAT MSDN article on installing VSTS. Recently he resolved something that I ran into last week on a new machine build - the fact that the Microsoft AntiSpyware Beta effectively kills Unit Testing with Visual Studio 2005 Beta 2 by blocking the resulting scripts from executing. When you execute your tests, the Unit Testing Framework will generate dynamic scripts (with dynamic filenames), and attempt to execute them - but the AntiSpyware app blocks execution, and asks you for approval to execute. The first problem is that VS 2005 completes execution and returns you to source view quicker than you can click the "Approve" button. In addition, because the filenames are dynamically generated, each subsequent execution creates a new script, and each are blocked in succession.

Dave's post with resolution instructions (turn off AntiSpyware's Script Blocking component) are located in his blog post.

Thanks Dave - You da man!

June 16, 2005 Presentation: Writing Quality Code with Visual Studio 2005 Team System

Scott Dockendorf — Sun, 24 Apr 2005 06:34:00 GMT

If you live in the Dallas, Ft. Worth metroplex, or plan to be in town on June 16^th, please join us at the Visual Studio 2005 Dev Con on June 16, 2005 at the Hotel Intercontinental in Dallas, just north of Beltline and the Dallas Tollway.

I will be presenting a session in the Visual Studio Team System, entitled “Writing Quality Code”, which will focus on the tools built into Visual Studio 2005 Team System that will make all of us better developers, including Automated Unit Testing, FxCop, PREfast and MSBuild. This session will be 4 days after the birth of our second child, so Starbucks will be a big player in my session.

Here are some links of importance.

Registration for this event is $99. Everyone who registers will receive VS 2005 Beta 2 DVD, SQLServer 2005 Beta 3, and an Visual Studio / MSDN Transition Guide.

BONUS: If you register before May 1, you receive two books, including: Introducing Microsoft ASP.NET 2.0 (MS Press) and Introducing Visual Basic 2005 for Developers (MS Press), a $60 value!

I hope to see everyone there!

May 12, 2005 Presentation: TDD & Unit Testing with Visual Studio 2005 Team System

Scott Dockendorf — Sun, 24 Apr 2005 06:11:00 GMT

Interested in Test-Driven Development? Live in the Dallas Ft. Worth Metroplex? Well, Scott Bellware (MVP From Austin, TX) has prepared an AWESOME (& FREE) day-long event that is open to the public.

TDD Workshop - Dallas, Texas - May 12, 2005 - Microsoft Las Colinas
UPDATE: Brian Moore's Writeup On The Event

ScottB has produced some GREAT content about TDD, and if you have any interest in implementing this approach at work - please join us. This isn't just a 1 hour overview and light demos, it will include presentations and demos in the 1st half of the day, followed up with a 4 hour hands-on workshop using such tools as NUnit, NCover, TestDriven.net

Registration will be on the Dallas .NET User Group website soon. Attendees will receive a copy of James Newkirk's Test-Driven Development book and prizes include a SPOT Watch, 2 Licenses of Clover.NET, and a Microsoft Fingerprint reader. Also included is the Attendee CD, which will contain a copy of all the slides, demo code, labs, and software needed to get started with TDD.

Fellow DGC-er and Regional Director Chris Menegay will present an overview of Visual Studio Team System, and I will present an demo-featured overview of Unit Testing, Code Generation, and Code Coverage using Team Sytem.

Planning on attending? Make sure to bring your laptop (if you have one). It's not required, but recommended for the afternoon lab sessions. If not, you can still follow along with ScottB.

After the event, please join the Dallas .NET User Group as they present INETA speaker Dan Whalin who will cover Xml & .NET 2.0.

May 2, 2005 Presentation: Test-Driven Development & .NET TODAY! at Oklahoma City .NET Developers Group

Scott Dockendorf — Sun, 24 Apr 2005 06:07:00 GMT

If you are in the Oklahoma City area on May 2, 2005, please join me during either the lunch or dinner sessions of the Oklahoma City .NET Developers Group, where I will present “Test-Driven Development & .NET Today!” This session will focus on automated unit testing, driving better software through Test-Driven Development’s unique approach, and some round-table discussions on lessons learned & recommended practices. I can’t wait to hear how the adoption of automated unit testing & TDD in the OKC marketplace.

The lunch session will be at the Hometown Buffet-North and will begin at 11:30. The evening session will be held at the Oklahoma City Downtown Library, and will begin at 6:00pm.

OKCPRO.NET’s Event Listing
Raymond Lewallen’s blog post on the talk (with kudos from TDD/Agile-stud Darrell Norton J Thanks for the kind words Darrell )

Thanks to fellow Developer Guidance Council member Keith Nicholson and the officers at OKCPRO.net for this opportunity. I’m happy to spread the TDD-love J and I hope the session speaks to everyone who attends.

New MSDN Online Article: Install Steps for Team System

Scott Dockendorf — Thu, 10 Mar 2005 19:25:00 GMT

Check out the new MSDN Online article, which provides guidance on how to install Team System (link below)

Installing the December CTP Release of Visual Studio Team System (by David C. Bost)

I'm going to read it in detail later tonight (after the premiere of the Star Wars III: The Revenge of the Sith trailer (Airing on Fox, tonight sometime during "The O.C.")

But from my first glance, it appears to be concise and easy to follow! Thanks David for the guidance!

Some Great RSS Finds

Scott Dockendorf — Wed, 02 Feb 2005 08:21:00 GMT

Here are some interesting “finds” from the blogging world over the past week or so (I’m offloading all my saved Favorites here!)

Agile Development

Check out www.xpstorystudio.com, JSGreenwood's free-Project Management portal for Agile teams!

Community Sites

www.Larkware.com (from Scott Hanselman)
List of Interesting Wiki’s (from Paul Bartlett)

.NET Open Source Software Projects:

Mvp.Xml Library v1.0 Released (News, Project Site) (from Roy Osherove)
Check out Roy Osherove’s Xtunit, Interception Block, & Extensibility Application Block
Newly-released Enterprise Library
(More Info, Download, Online Tutorials, Community Extensions)
Wintellect’s Power Collections (Generics for .net 2.0)

ASP.NET

Use ASP.NET 2.0’s Member Management Component in ASP.NET 1.1 (From Brian Ritchie & Telligent’s own, Scott Watermasysk)
New sharpUrls Library (from Fabrice’s blog)

.NET Framework

Fredrick’s Post about the new ConfigurationManager Class in .NET v2.0
David Waddleton’s 5-part webcast series over Debugging & Tweaking starts on February 14^th.
An interesting look at the StringBuilder vs String Concatenation (I haven’t tried it myself, yet)

VSTS

MSDN Universal & VSTS, How Will It Work? Clarification on pricing (from Buck Hodges)
VSTS Newsgroups (also from Buck)
Ohad’s Comparing VS 2003 with Visual Studio 2005 Team System Post

BizTalk

BizTalk Roadmap Announced (from BizTalk ChalkTalk blog)

New C# Team member Blogs: Shaykatc & MSDN C# Team Blogroll

Microsoft MVP’s

MVP Awards & 2005 MVP Global Summit Date Announced (from Jean-Luc David)

Smart Client Deplyment

MSDN Article: ClickOnce vs MSI (from .NET Security Blog)

FireFox

Speed up FireFox (from Scott Hanselman)

Reply to Scott Bellware's Review of my Unit Testing with Whidbey article

Scott Dockendorf — Tue, 25 Jan 2005 23:24:00 GMT

Scott Bellware, INETA Speaker Chair, Microsoft MVP, and Austin .NET User Group President recently posted a review of my .NET Developer’s Journal Article, “Unit Testing with Whidbey”.

The article is located here: (Web-based article, Entire Issue PDF)
Images are located here
His review is located here.
My response is this page :)
Update: His response to my response is here:

Quite honestly, I truly thought that (a) mentioning TDD in a “Unit Testing with Whidbey” and/or (b) promoting a interface first approach to TDD would cause a stir among those who following the traditional TDD approach (create tests before ever writing a line of TDD code). I just wanted to go on the record and help shed light on the article, why I wrote it the way I did, and my intended audience.

My response (as posted in his blog here) is as follows:

<< In reading and re-reading the article, I'm left feeling quite unsure whether I know where Scott is coming from, and I find it hard to distinguish when he's talking about plain old unit testing and Test-Driven Development.It's a good overview of VS 2005's support for unit testing, and it harkens the coming focus that will be given to unit testing in the next generation of .NET development.>>

Hey Scott,

After talking with Chris Menegay, I had a feeling that it would strike a cord with you. J Seriously, I appreciate your input, and you made many valid points. I wanted to help shed some light on the article, and why I wrote it the way I did:

<< In some cases, I found the TDD moniker used in context in a way that was misleading and adding to TDD misconceptions. I fear that I might just be reading the article from the wrong perspective and not seeing some of the points being made, but I fear even more that others might misread the article as well, and make their first forays into TDD on shaky conceptual footing. >>

The focus of this article was to highlight the new Unit Testing Features of Whidbey (Visual Studio 2005). It was not intended to be a comprehensive review of TDD, nor mention current open-source applications available today, including TestDriven.net, NUnit, csUnit. Also, I only had 1,500-2,000 words to work with, which forced me to summarize where necessary. I had to remove almost all my Refactoring content due to this reason (yes, it made me sad too).

Why Mention TDD Approach?

There were 2 reasons that I mentioned TDD in the article. First, I too (along with you) am fond of the TDD methodology. I’ve been using it for a few years now (using NUnit), and love it. Through my “giving back to the community” interests, I wanted to introduce TDD to those who are new to the methodology. To me, it makes sense to at least mention TDD when it pertains to Unit Testing.

For the second reason, let’s compare and contrast the two common TDD approaches

	Approach #1: Test-First	Approach #2: Code/Interface First
Description:	Born from Extreme Programming methodology, was the initial implementation. This is the traditional approach	Evolved after birth of Test-First, where Interfaces are created before the tests
Where does the “Design” occur	During TDD cycle	Up-front, when designing the solution.
Steps:	Design Code your Tests Run Your Test – (.NET Compiler won’t let you continue, because you’re referencing objects that don’t exist yet Fix Compile Errors by creating object with public interfaces (as defined in your test) Rerun Test – Watch them fail “Red” Complete Implementation Code Rerun Tests – Watch them pass Review Code / Refactor as necessary Go Onto The Next Test	Design Code your Interfaces based on your design Code your Tests Run Test – Watch them fail “Red” Complete Implementation Code Rerun Tests – Watch them pass Review Code / Refactor as necessary Go Onto The Next Test

Now, let’s look at the “selling points” for using Whidbey as your Unit Testing engine (at least with Beta 1 Refresh as I used for the article)

Integrated UI (Test Management, Categories, UI to select individual tests) – These are nice features, really independent of which TDD approach you use
Code Generation (from Object Interfaces)– This is impossible to “sell the concept” to individuals following the test/code/refactor approach, because you have no object interfaces to generate code from – the tests come first.
Integrated Access To Code Coverage – This is a nice feature, but independent of which TDD approach you use.

Thus - you might agree that “Code Generation” isn’t a benefit for Approach #1 – Test First Developers, because the interfaces come from the tests, not from the project design (i.e. you don’t have an object interface to generate code from). Thus, I couldn’t write an article based on the Test-First approach. It is, however a big benefit for people who follow Approach #2, which is why I chose to use that approach in the article.

My personal beliefs is that TDD can benefit any development environment using any approach. I know there are those who only recognize Approach #1, and I respect that. My experience in consulting has led me to believe that any approach/methodology needs to be flexible, support team development, and conducive to change. IMO (which is all it really is), Approach #2 offers that.

During my TDD talks that I’ve presented at our local .NET User Groups, I was always asked with the same concern = “all that extra code!” I agree that this is a misperception, and wanted to discuss my ideas on that topic. I thought that people who follow Approach #2 might benefit greatly from Code Generation, which is why I decided to include it in the article.

For those who don’t recognize Approach #2 as a valid methodlogy, I completely understand why the article might be confusing. I stated at the beginning of the article that the article focuses on Approach #2, and not Approach #1. However, based on your review, I don’t think I made the point clear enough. (In fact, I had to remove the comparison table for space considerations). Thank you for that, and I will clarify that stance in further articles and presentations.

<< 1. Thoroughly design your software. Know exactly what the software must accomplish before writing a single test.
Point number one gave me pause. It may just be the way Scott chose to word this point, but it can be taken to mean something that couldn’t be more at odds with TDD and XP. TDD process helps achieve good design (good and simple is the goal), but it doesn’t necessarilly start with good design, and certainly not often with thorough design.>>

You bring up a great point in Approach #1 vs. Approach #2. Using Approach #1, the design starts and ends with your TDD cycle. Using this approach, you have a basic idea on how you want your code to perform, and use the multiple test iterations to refine your design. Environments that use Approach #2, tend to design their projects up front, possibly because those shops follow traditional waterfall project management and need to show a design before obtaining the resources to staff the project. In this case, the design could be close to completion before development begins.

Why do I feel this way? My consulting experiences include many different types of industries and different functioning development shops. I’m not bragging, but just to drive home the point that, only a few of these shops use Extreme Programming – many use traditional waterfall approaches – which require LOTS of documentation and planning before development begins. In addition, from a consulting standpoint, especially during the .com bust, many of our clients would have not supported XP (dual programming model, lack of documentation, etc..). IMO – TDD still works for these shops, just using Approach #2.

<<That said, having solid requirements and writing low-level stories is good and desired, so I'm confused. I don’t know if Scott is saying do detailed design up front, or have good requirements up front. >>

Very good assessment on my choice of wording. I should have mentioned solid requirements in addition to design.

<<In point three, Scott confuses me with the use of the plural "tests" in "Use design requirements to build and execute tests", and the use of "them" in "and watch them fail". >>

I should have asked you to tech review the article before going to print J Another great point, that could present a grey cloud above those new to TDD. This statement should have been reworded to talk about executing the process for each individual test.

<<In point number five, Scott seems to suggest that code tweaks and refactoring are one and the same. I not sure that I would personally wholeheartedly agree with the equivocation of refactoring and tweaking for performance or even structure. Although Scott references Fowler's refactoring catalog, so I guess he's just kinda using some jargon when making this point. And in truth, I guess it's the jargonizing of agile approaches that I'm trying to shed some light on. In this particular case, I would want to stand up (and I guess I am) and say that tweaking and refactoring are not equivalent.>>

LOL – no I didn’t throw in Fowler reference to give the paragraph validity. As mentioned earlier, I had to cut out all my refactoring examples due to space constraints. And I couldn’t agree more – tweaking & refactoring are not one in the same. Tweaking is just that, resolving small issues. Refactoring is much more involved and could be a whole article/book in itself. My initial cut was 3,600 words (way over the limit), and since I committed the article to focus on the new features of the Whidbey Unit Testing engine, I had to cut it out of the article.

<< Test-Driven Development is a design discipline. TDD is a rigorous programming methodology that brings the levels of formalism previously only found in OO analysis and design methods down to the level of designing and constructing code and into the hands of the programmer. Unit tests are a side effect of TDD. If you're generating tests from pre-coded classes, chances are you're not doing TDD. If you're generating tests from pre-coded classes, and you've never really done any unit testing before, and you assume that you're doing TDD, chances are that TDD is going to go sailing right over your head, maybe never to be seen or heard from again. >>

Another great point, and something that shouldn’t have been cut out of the article. I had 3 or so paragraphs on this point, stating that simply having LoadTest & SaveTest methods on an object that has Load & Save methods is not sufficient. As a TDD developer, you MUST think outside the box, figure out every conceivable way that your object will be called, used, destroyed, etc… You will end up with MANY more tests than methods on your object – if not, then you’re doing something wrong. Take for example a Load method on a CRUD object. You’ll want (at the bare minimum) tests for

Postive Scalar Load
Negative Scalar Load
Postive Multiple Load
Negative Multiple Load
Security Tests (to test for SQL Injection, etc..)
TearDown Tests (if the objects plan to do any COM interaction, or have Dispose logic that you want to test)

While we might “agree to disagree” on the benefits on Approach #2, I hope this post helps clarify my approach, and that we’re not really that far off, from a TDD evangelism standpoint.

I appreciate your honest review.