We've been using Rhino Mocks as our mocking framework for the last year and have had some good success with it.  Previously, we were writing our mocks by hand, which was a major pain in the ass.  While Rhino Mocks offers a lot of great features and has aided our testing efforts in many ways, it has also caused us some pain.  I've recently been hearing a lot of "buzz" about Moq, a new mocking framework developed by kzu.  This morning I read Daniel's "Why do we need another .NET mocking framework" post and I'm convinced that I need to give Moq a try.  A lot of the points in his article ring true to me, and make me wonder if I would prefer Moq over Rhino Mocks.  The interesting thing with trying a new mocking framework when you're involved in a large project that has already made a considerable investment in another mocking framework (Rhino Mocks) is how you go about trying it, and what you do if you prefer it to what we're currently using.  Ah the joys of software development.

I found the following links on the Moq google code homepage interesting:

• Why you will love Moq (with screenshots!)
• New Moq features for mock verification and creation
• Mocks: by-the-book vs practical
• What's wrong with the Record/Reply/Verify model for mocking frameworks
• State Testing vs Interaction Testing
• Mocks, Stubs and Fakes: it's a continuum

Over the last two months I've thought endless times about starting a series of posts on Behavior Driven Development (BDD). Starting sometimes late last year I began reading up on BDD and trying to wrap my head around what it was, how it was different then TDD, and why I should care. I started to hear a quiet buzz from a number of people in the community regarding BDD, so I figured at the very least I should give it a look. Right around this time Brian Donahue was rounding up speakers for the Philly .NET Code Camp. To make a long story short Brian and I decided to do a joint presentation on BDD.

As I prepared for our presentation I read as much material as I could online about BDD. Some of the sources of information that stuck in my head include:

• http://dannorth.net/introducing-bdd
• http://behaviour-driven.org/
• http://video.google.com/videoplay?docid=8135690990081075324

While I think I've gotten much closer to understanding what BDD is about, I think there is still a good bit of discussion that needs to happen in the respective communities that are looking to adopt BDD. Although I've been too busy lately to follow any of the mailing lists I'm subscribed to, I do drop in from time to time to see what I've been missing. It seems as though a nice conversation is developing in the altdotnet mailing list regarding BDD Issues. Additionally, a Google Group on Behavior Driven Development has been created which will hopefully provide the same kind of community for BDD as we have for TDD, DDD, and all our other double D topics.

In an attempt to further form my thinking on BDD I'm going to be putting my thoughts down on "paper" (aka this blog) in the coming weeks and months.

Over the weekend I listened to the latest .NET Rocks episode with John Lam.  I'm very keen on seeing and hearing about where the IronRuby project is going, so I found the interview very informational.  Although I enjoyed the entire show, one particular exchange between Carl and John stood out.  About half way through, Carl asked John whether he thought developers who don't do test driven development (TDD) and unit testing should be working in dynamic languages.  John made the wonderful assertion that he doesn't believe programmers that are not writing "unit tests" should be writing code in any language, regardless of whether the language is dynamic or statically typed.   Following that statement, John went on to mention that whether or not the code is test driven isn't nearly as important as whether the code has unit tests since the "test driven" approach is "extreme" and "dogmatic".  While I agree that the key is unit tests, I don't agree that a test driven approach is extreme or dogmatic.  In my opinion its the most pragmatic approach to writing code that is well designed and well tested.  The fact is, writing unit tests after the fact sucks!  Especially if "after the fact" is days or weeks after the real code is written.

When I first got started with TDD I didn't really understand what it was all about.  Rather than figure out what this magical red-green-refactor thing was all about I decided I'd just write some unit tests once I had my code written.  After a couple projects using this approach I started to realize that I really hated writing unit tests after the fact.  It was because of this hatred that I got started with test driven development.

Rather than testing being a pain in the ass task that I had to do when I finished writing my "real" code, testing became an instrumental step within the process of writing the "real" code.  Since I was using tests to figure out what code needed to be written, it became a vehicle by which I could design the code I was writing, rather than an afterthought.  I'm sure there are people out there that write great tests after the fact, however, I'm not one of them.  For me writing tests first isn't something extreme or dogmatic, it simple the only way I can write high quality code with solid test coverage without going nuts.  For me, writing unit tests after the fact sucks.  For me, driving my code with tests is a joy. 

I wonder how writing tests first could be "extreme" and "dogmatic" for others, but for me its pragmatic?

   

This past week, while working on a couple updates to some existing code I had to update the corresponding unit tests to ensure the stuff I added didn't cause massive problems.  As I started exploring the unit tests for the existing functionality my head started to spin.  Either I was going nuts, or the tests were less than ideal.  After examining the code for a little while I started to see why my brain wasn't working so well when it came to examining this particular chunk of code.  While the tests were testing the functionlality that they needed to, they weren't nearly as readable as they could have been.  Some of this is a result of attempting to reduce the amount of duplication within the test class.  You see, several things needed to assert the same things, so they were seperated out into a method that you could pass some stuff to, and it would magically assert everything that you could ever want asserted upon the so said "stuff".  While nice in concept, it led to code that was very hard to follow.  In order to see what an individual test was doing I needed to jump around to 3 or 4 methods that contained the asserts.  Once I finally tracked down the asserts that were being used I was able to see what was expected.  It just so happens that I could also see that we were testing the same thing 3 or 4 different times in an individual test.  For good measure, we also appeared to test the same exact logic in multiple tests!  All of this has led me to the following conclusions:

• You should prefer readability over well factored code for unit tests.  If you need to jump all around to figure out what you're testing something's wrong.  If duplication helps with readability, duplicate away!
  
• Make sure your unit tests are only testing one thing. 
  
• Make sure you don't re-test the same thing over and over and over again.  Taken with the above point, you should begin to see that you shouldn't have that many tests that need to assert the same thing, if you do, you probably have multiple tests testing the same thing.
• Only tests one class per unit test class.  If you're testing ClassA and it leverages logic within ClassB and ClassC, don't test ClassB and ClassC's logic within your test for ClassA.  Create seperate classes for ClassB and ClassC.  Trying to test them all in one place will lead to unit tests that are too hard to read and doing too much.  This is particularly hard to keep in mind since often times as part of the process of doing test driven development ClassB and ClassC might be created.  It's tempting to leave the existing tests that test the logic that used to be in ClassA but has since been moved to ClassB and ClassC within ClassA's tests.  Don't do it, move the tests to the suite of tests that you're creating for ClassB and ClassC.  You'll thank yourself when you come back to change that logic, since it will be where you expect, rather than in a test class for a related class.

I've gotten distracted by Lilo and Stitch so I'm going to stop with my conclusions there, and go play some indoor basketball with my son who is throwing a basketball all over our house. :)

[Disclaimer: It should be noted that I'm pretty sure the code I was looking at was code I wrote...whoops :(]