Scott Densmore warned me not to blog about this, but I just couldn't resist.  Apparently, there is a huge uproar regarding unit testing in the next version of Visual Studio.  Peter Provost (the “instigator” :->) was working the blogging channels to lobby the folks in the Microsoft Developer Division to make unit testing a standard issue for all versions of Visual Studio.  Credit to Peter for a pre-emptive strike -- I don't think they've made the decision yet, but a little grassroots proactivity never hurt anyone.  As yet another MS employee, I certainly support whatever decision the VS guys make.  That said, I am very curious about how things turn out.  On a slightly different twist to the VS Unit Test debate, I know Jim Newkirk recently blogged with an interesting perspective that we seem pretty wrapped up in unit testing and haven't given as much of a focus on the other very important tools that out there (note to Jim:  don't give everyone more to complain about ;->).  But I think one of the feedback messages said it best--unit testing and test driven development comes off as so natural that it is easy to assume that it is a fundamental part of development.  Here's the thing--long before test driven development existed, people tested their methods and classes with “test code“.  I feel like back in the day, my mentors at Intel used to prescribe three lines of test code for every line of app code.  Of course, I would write the code in the void main ( ) and then delete it (or if I was “smart“, I would comment it out temporarily).  When I made modifications to the code, I'd either re-write the test code, uncomment the commented code, or just wing trust that things worked with my tweaks (“what could possibly go wrong“).  But beyond the perils of modification that drove me into days of debugging because I couldn't find my newly introduced bug, I can't begin to tell you how many times a line of “test code“ burned me because I left it in thinking it was production code.  Now, I won't say I was the most structured programmer in the world (OK, I was so downright sloppy that they sent me to business school as punishment :>), but looking back, my method sounds comical given the structure, discipline, and automation that test-driven development provides.  But here's the key:  NUnit makes the bar to adoption so low that you can't help but try it.  And once you do, you're hooked.  You feel more confident about your code.  You get the satisfaction of seeing all tests passed and it's clear what your code can/can't do.  It's less about optimizing your code and more about doing what you were doing, but doing it 50 times smarter just by adding a little structure and semantics around the test code you were already writing.  So, I can emphathize with Peter and the rest of the movement looking to make unit testing standard in Visual Studio.  I don't know if restricting it to a particular edition will cramp adoption, though it certainly won't help.  That said, I think Jim's point about integration of the tools is extremely valid and the other tools he speaks of are really the ones that need the “endorsement“ of Visual Studio Ubiquity.   But, in defense of the VS guys, it's not that easy.  The eternal balance of trying to sell products and simultaneously help customers is always a challenge.  We still have many months before release and I think a lot of decisions need to be made. I'll be waiting and watching just like you guys.  Stay tuned!

{Moby - 18}

Skip to main content