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

Paying Attention to MVP, Presenter First, Castle, MonoRail, Igloo, et al

by Jon Davis 23. July 2007 00:34

In order to be an excellent software developer, one must be able to communicate and interoperate with others' software excellently. Lately, deafening chatter has been overwhelming the software communities about MVC, MVP, Presenter First, Castle, Spring, MonoRail, and so on. To my shame, I was so focused for so long on embracing OOP and the C# language and the .NET Framework and general Microsoft APIs and technologies that I overlooked these essential patterns, practices, and tools used by software professionals the world over. If I had only swallowed MVC and XP years ago, I would not be struggling so badly to play catch-up.

So far I haven't actually written a single line of code yet based on these patterns. I have looked over the shoulder of our team architect who was trying to get into it, and in so doing got a snapshot of what MVP code "looks like" (lots of interfaces and event handlers). After listening to Atomic Object's ArcCast podcast interviews, I've read Atomic Object's PDF presentation on Presenter First. I've realized the value of mock objects, and I've heard about Rhino Mocks. I've learned about Inversion of Control and dependency injection, and implementation tools for these in Spring.Net and in the Castle Project. I've been looking around for how MVP is supposed to work correctly in a web-based environment, where view state is already URI-controlled (unlike a GUI app, where the controller / presenter can push a view change more immediately). I've come across MonoRail and Igloo, but except for coding shortcuts I still don't see a solution to this problem.

But I haven't actually started using any of them.

I still haven't figured out whether these processes, patterns, and tools are directly related to those of Agile and XP. I do know that all of these are directly tied to unit testing and testable software--a critical process of software development I have tended to abhor, to my awful, disgusting shame.

I have an "Agile Princples, Patterns, and Practices in C#" book sitting on my lap, and I'm trying to figure out whether I should delve into this book, or if I should start tinkering with Castle to lead to MonoRails, or tinker with NUnit, or with NMock, or Rhino Mocks, or what. Maybe it doesn't matter, as long as I delve into one of these and progress myself.

I am certain, however, that by the end of this year, I had better know and be practicing all of the essentials of the above, or I will not feel confident in calling myself "excellent".

Update: After reading the forewords and the prefaces of Agile Principles, Patterns, and Practices in C#, I am pursuaded, this is the path I should take right now. This should be a book I should try to read end-to-end. While the subject is not related to MVC/MVP/PF, etc., I'm pursuaded that XP / Agile programming is a skill that is mandatory to understand as a software professional. It is about working with people, test-driven development, changeable software, and core values. MVP is just one technique for process and pattern, but it does not fit all. XP/Agile knowledge, however, might actually be one-size-fits-all. We'll see.

Be the first to rate this post

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

Tags: , , , , , , , , , , , ,

Software Development


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


<<  May 2021  >>

View posts in large calendar