Test-Driven Development in Microsoft .NET (Ch. 1)

by Jon Davis 24. July 2007 21:45

Last night I read the first chapter of Agile Principles, Patterns, and Practices in C#. Summary:  Essentially, the Agile Manifesto, expounded.

This afternooon I just cracked open the introduction and Chapter 1 of Test-Driven Development in Microsoft .NET (Microsoft Professional). Summary: The basic, trivialized definition of TDD is 1) Never write code without starting with a breaking test, and 2) never repeat yourself. Test-driven development is apparently not about sitting around testing code like a QA engineer stuck in hell like I thought it would be. It's about writing code in tiny increments until each increment is working flawlessly, virtually eliminating the process of debugging. (Funny, that sounds very similar to a quote I saw after installing #develop a year or two ago. Something like: "The best way to write code is always to start with one small requirement, test it thoroughly, then add to it and repeat the process, until all requirements are complete.")

The section called "Red/Green/Refactor" is (I've seen this before, in a diagram in the Presenter First PDF from Atomic Object):

  1. Write the test code.
  2. Compile the test code. (It should fail because you haven't implemented anything yet.)
  3. Implement just enough to compile.
  4. Run the test and see it fail.
  5. Implement just enough to make the test pass.
  6. Run the test and see it pass.
  7. Refactor for clarity and to eliminate duplication.
  8. Repeat from the top.

This is an older book, a couple years, but still relevant. It focuses on NUnit which everyone is still using, although today I discovered MbUnit, which seems to have more features, but it's recommended by some to start with NUnit until you need some of MbUnit's extra features. I've also installed TestDriven.net but not sure what it offers yet.

Tonight before I get out of here (I'm stuck at the office and it's 10pm..) I am going to go through the Appendix A of this TDD book which is an NUnit primer.

Update: *click*. This happened to me when I realized that programmer tests are executed in bulk with a click of a button, and grow as your project grows, so if requirements change you can see what breaks from a tweak just by re-processing your programmer tests. No more manual trudging, no more "if it breaks, enter debug mode" start-to-finish manual tests. Those have to happen, too, but before they do you can quickly and easily see exactly where red flags are raised before you even get that far.

Currently rated 1.0 by 4 people

  • Currently 1/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Software Development


Add comment

(Will show your Gravatar icon)  

  Country flag

  • Comment
  • Preview


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  June 2021  >>

View posts in large calendar