QUICK THOUGHT: The engineering practices in Extreme Programming (Like TDD, Pair Programming, etc) can lead you to improving your code. But it won't do it for you. TDD will point out design flaws, but it won't GIVE you good design skills. If you write lousy code, you'll find it very hard to maintain practicing XP, but XP won't MAKE your code better. You still have to do it. You STILL have to read books, write code and share with other developers. KAIZEN! ~Lee

When testing, I find that it is important to be cognizant of what you’re testing. I’ve seen (and done) tests where I was using my IoC container to inject a dependency. You may think, “That’s the way it will work in the real world.” The problem is, it may have nothing to do with the System Under Test (SUT). So, you’re test might fail because something went wrong with your IoC container or configuration and have nothing to do with your SUT failing at all. The important thing to remember is test what...

While traditional syntax for asserts is fairly easy to understand (once you get used to reading it), it doesn’t read as close to English as I’d like. So I have taken to using the Assert.That syntax for a lot of my assertions. This makes an assert like this: 1: Assert.AreEqual(5, SUT.Items.count); Read like this: 1: Assert.That(SUT.Items.Count, Is.EqualTo(5)); To me, the second assert reads a lot more like plain English. ~Lee...

I was trying this morning to run NCover (for the first time). I downloaded a eval copy (sweet!) and then opened NCover Explorer only to find myself a little lost. So I thought I'd RTFM a bit first. That helped (a little), and the documentation online also helped some, but what I really needed to do was check my MSTest test coverage of my base framework. The documentation really only covered generic scenarios and a little bit of googling only left me wanting. All these little bits and pieces, however,...

For someone like me, who has never traditionally done test-driven development, it sucks. It's hard to get used to writing the test first, then when you write your test, it's easy to start writing the code to make the test pass and forget that you're doing TDD and just continue coding. It's also hard to know WHAT needs to be testing and HOW to test everything you need to, at the appropriate isolation level. To add to my frustration, I starting my first fully test-driven project (on my own) and learning...

As I get settled in at this new job, I begin to take stock of what the company wants to accomplish: a solid, extensible product with the longest possible useful life. Given the fact that this product will probably take 2-3 years (total) to develop, that means learning the newest stuff and looking at some technologies that have yet to be released. The new technologies coming out of Microsoft in the next six to twelve months is staggering. Beyond products (like Windows 2008, SQL Server 2008 and Visual...

I am creating a blog engine. Not because the world needs another, but because there are some techniques I want to learn about and creating this very straight-forward project will allow me to do that. First step was to create the project and start experimenting with Test-Driven Development inside MVC for ASP.NET. I started by searching for TDD MVC and ASP.NET which led me to this article by phil haack. While trying to put together some of my first tests, I had to use a mock object. The easiest way...