I have been working on a project with my wife the last few weeks. Since this is a totally personal project I am free to use whatever tools I want to use without having to justify my decisions to a team.

So I have been going nuts with the tooling. I set up a SVN repository on my Windows Home Server. I set up TeamCity and two separate CI builds using UppercuT that run NUnit tests, NCover code coverage analysis and NDepend reports. I am writing my app using ASP.NET MVC and the S#arp Architecture frameworks. Heck, I’ve even setup Selenium tests that get run every night. And I have NHibernate Profiler wired in there too JUST BECAUSE I CAN. It’s a lot of infrastructure set up for one page so far. 8)

So when I couldn’t get my single Selenium web test to pass in the TeamCity nightly build, I was a bit obsessed with figuring out why. Turns out, I had made a modification to a test base class that was causing the problem. I didn’t discover this issue when I created it because I typically don’t run Selenium tests prior to check in. I prefer to let the nightly build do that. So it took me a couple days to figure it out. Which prompted this post to Twitter which made its way to Facebook:

Yo Dawg, I heard your build failed because you refactored your unit tests. So, I wrote some unit tests for your unit tests, so you can...

To which my buddy Drew Welliver, an awesome developer over at L&I, commented:

Code so nice... I refactored it twice, then thrice, then.... At some point ya gotta wonder, wouldn't it have been easier to just run the application yerself and find the friggin' bugs?...

And followed up with:

And code coverage is cool, but scripts running code running scripts running code running scripts running... The users are still gonna break it, SOMEHOW....  And all that testing becomes academic.  The reality SEEMS to be that when I've worked on systems that used testing frameworks, their bug lists never seemed to be any shorter than the ones that didn't.

The Fallacy of Unit Testing Proving Quality

I don't think any TDD-er will say they don't produce bugs because they have tests. I would hope that it makes you think about your code a bit more and help you to discover more bugs prior to them getting out, but you never know if you are testing the right assumptions.

I do know that, if I have a bug and I write a test that demonstrates that bug, I know I have fixed it when that test passes and that that test gets run every time a check in is made to  source control, ensuring that bug never returns.

The value of unit tests is not only the immediate feed back that the code you are working on does what you think it does but also sustained confidence that that code still does what you think it does though out the life of the development effort and beyond.

Spending ten minutes writing a test that gets run thousands of times though out the life of the project and into the maintenance phase of the product lifecycle is value.

Additional Benefits

A tight feed back cycle between change=>flaw=>fix does yield better code. The wider your gap in feedback cycle the longer it will take you to fix the problem because you have to reestablish all that context.

If you have to monkey test over the course of days, how do you know what change might have caused the problem? (no offense to monkeys of course)

The bottom line comes down to this question:

 "Have you ever hesitated to make a change in a large system because you had no idea what effects it might have elsewhere in that system?"

A logical ,well thought out test suit gives you the confidence to make that change. If your tests start failing you simply back the change out right then and there and try something else while you have all the context for what you are working on.

The alternative of waiting days to weeks for unmotivated half qualified monkey testers to find that bug and then wondering which of the 40 change sets checked in during that time might have caused the issue is not one for me.

And Drew, I take you up on that beer offer brother. I am always down for testing out some beer.

UPDATE: And you want hard numbers? Here are some hard number for you.

I was just reading Ayende’s post on coding pitfalls and it’s associated comments. This struck me as less about pitfalls and more about pet peeves. A personal pet peeve of mine is when I discover a block of code that makes multiple calls out to fetch a single value while processing.

For example:

if(Call.ToSomethingByName("Name") != "foo") {
  if(Call.ToSomethingByName("Name") !="bar")
    var something = Call.ToSomethingByName("Name");
    processNonFoos(something);
  else
    var someotherthing = Call.ToSomethingByName("Name");
    processFoos(something);
}

Just seeing this kind of construct tells me the person who wrote it was not thinking about anything other than “make it work”. They were so focused on getting the task at hand done and moving on they didn’t stop to think about the all the possible gotchas and potential failure cases.

This code was most likely tested by hitting F5, plugging some text into a form and clicking submit. As long as no errors were thrown the developer moves on to the next task.

Just looking at this code, how many possible failure points do you see? What happens if Call.ToSomethingByName(“Name”) return null? What happens if Call.ToSomethingByName(“Name”) makes calls to the database? What happens if Call.ToSomethingByName(“Name”) returns something different on each call?

UPDATE: Looks like I may have jumped the gun with this review. The actual print version is due to be released in September 2009. So the content may change a bit.

I am a huge fan of Manning’s Early Access Program. I get to read books on new technology as they are written. It is almost like the authors and I are learning about the topic together. Every few weeks an update arrives in my inbox and I upload it to my Kindle via Amazon’s conversion service.

A few weeks ago, the final shipping edition completed chapter of ASP.NET MVC in Action hit my inbox and after getting it on my Kindle I forgot about it for a few weeks. I have a personal project that my wife and I have been talking about for a while now that I want to write using MVC. So, as a way to get myself in the right mindset I sat down and read the book cover to cover recently.

The book is broken up into four major sections. Chapters 1-5 give you an in depth overview of the core concepts of the MVC architecture. Model, View, Controller and Routing all get dedicated chapters that give you a firm understanding of their purpose and usage.

The second section of the book covers the various extension points of the framework as well as application architectural concerns. View Helpers, Partials, Components and Action Filters are all touched on.

The third portion of the book is a kind of  of hodgepodge of topics. MonoRail and Ruby on Rails get a chapter that gives some historical context on the topic. Hosting and Deployment are covered to help you figure out how to get MVC running under IIS6 or IIS7. “Classic” ASP.NET tooling is covered to give you an idea of existing tools and techniques that applicable in the new framework.

The final section of the book wraps everything up nicely with some guidance with Best Practices and a set of Recipes to get you started.

I can recommend this book as a great place to start on your journey into ASP.NET MVC with a couple caveats.

This book is not for beginners. It assumes you have a significant amount of ASP.NET development under your belt. And by “ASP.NET Development” I do not mean dragging and dropping controls on Web Forms. If you have implemented IHttpHandler or pages that do not require View State this book should be right up your alley. On the other hand if GridView is your best friend because it handles everything for you… maybe this book is not so much for you.

This book is highly opinionated. The authors are prominent figures in the ALT.NET community. There is a certain amount of agenda pushed in this book. Concepts like DI/IoC, Unit Testing and ORM are not only mentioned but are actively demonstrated as best practices. When available open source projects are used in examples and Microsoft tooling are more or less shunned. NHibernate, StructureMap, NUnit, MVCContrib and the current state of the art in ALT.NET toolbox all make appearances. Jeffrey Palermo’s Code Camp Server serves as the sample application through most of the book.

This is not so much of a problem for me as this is Kool-Aid that I have openly drank and serve to others around me. I use these tools, I understand their value and enjoy seeing them being used in examples in a book. Others who prefer to be fed the Microsoft story line by line wanting to only stick to the nuts and bolts of the technology might find this distracting.

In the end Jeffrey Palermo, Ben Scheirman and Jimmy Bogard not only did an excellent job of putting together a great practical guide to ASP.NET MVC they also successfully embedded some subversive ALT.NET concepts that will hopeful make us all better developers. And at the end of the day that is a damn fine accomplishment.

ASP.NET MVC is all the rage right now in the .NET space. But did you know that MVC is a pattern that has been around for decades? And there are other communities of developers that have been using it to produce websites for years. Here are a set of videos from the Ruby on Rails community about the common pitfalls in MVC development.

• MVC Public Service Announcement #1 - Controller Obesity
• MVC Public Service Announcement #2 - The Importance of Tests
• MVC Public Service Announcement #3 - Keeping Views Stupid
• MVC Public Service Announcement #4 - Staying RESTful
• MVC Public Service Announcement #5 - Outdated HTML
• MVC Public Service Announcement #6 – Modularity
• MVC Public Service Announcements - Out-takes

The Norwegian Developers Conference was held last month on June 17-19^th. From all accounts this conf was bordering on epic. The videos of each session have been posted on the website and it might be worth taking a look at them.

Some points of interest:

Michael Feathers

• Seven Blind Alleys in Software Design
• Working Effectively with Legacy Code

Scott Hanselman

• Deep Tour of .NET 4

Uncle Bob Martin

• Clean Code: Functions
• Clean Design: SOLID Principles I and II
• Clean Design: Components Principles

Udi Dahan

• Reliability, Availability and Scalability – How to have your cake, and eat it too
• Intentions and Interfaces – Making Patterns Complete
• Asynchronous Systems Architecture for the Web

Ted Neward

• The Busy Developer’s Guide to ECMA (Java)Script

Jeremy D. Miller

• Presentation Patterns for Composite Applications
• Convention over Configuration applied to .NET
• Software Design and Testability

Roy Osherove

• Understanding Test Driven Development
• Unit Testing Best Practices
• TDD: Using Mock Objects

Ayende Rahien

• Building Scalable Systems
• Inversion of Control & Dependency Injection: Breaking out from the Dependency Hell
• Producing Production Quality Software