As more programmers are getting excited about test driven development (TDD), one concern I am
hearing more these days is "my tests and mocks make it hard to refactor code."

Remember we took a while to learn how to write better code. Similarly we will take a while to learn
how to write better unit tests.

I want to talk about unit testing and mocking here with an example that was brought up yesterday at
the (#sdtconf). A fine gentleman Zachary Shaw lead an open space discussion on the Hollywood Principle
and mocking. A number of very bright programmers who're very passionate about TDD were in the session.

When talking about the principles, etc. Zack demanded a concrete example. We tossed around a few examples
and I mentioned my friend David Bock'sPaper Boy example. Taking that example and tweaking it to our
discussion and desires (as we programmers often do), we ended up with something like this:

public class PaperBoy {

   public void collectPayments(List
      customers) {

      for(Customer customer : customers) {

      customer.getPayment(this, 200);

      }

      }

      //...

David, in his example, does not suggest that getPayment() accept an instance of PaperBoy, the example in our
discussion deviated from his example rather quickly.

Now, how would the getPayment() method of the Customer look like?

public class Customer {

   public void getPayment(PaperBoy paperBoy, int amount) {

   if (hasNoMoney || doesNotCareToPay)

   paperBoy.stiff(this);

   else {

   deductMoney(amount);

   paperBoy.acceptPayment(this, amount);

   }

   }

   //...

It was suggested in the discussion that, in getPayment() method, the customer may decide to pay or based on some
condition may decide to stiff the paperboy.

So, how do we unit test this getPayment() method? Most of us readily agreed that we should mock-out (or stub out
or spy out, it does not matter for our discussion here) the PaperBoy. That will help us run the unit test on the
getPayment() method by isolating the PaperBoy.

Not so fast. Yes, if the getPayment() method has to be written like above, then mocking out PaperBoy may be one
way to unit test it. However, there are at least three problem (that I can think of at the moment) with the above code.

Problem 1. The above code has some unnecessary coupling and bi-directional relationship. The Customer depends
on PaperBoy. That is a coupling that I would seriously question.

Problem 2. The unit test is now made to do more. It has to create a mock of the PaperBoy. Even if you tell me it is not
much code, a single line of code that is not absolutely needed is a lot of code IMHO. You don't have to maintain code
that you do not write.

Problem 3. Are you really stiffing the PaperBoy? Who decides that? Can a paperboy decide that under very hard economic
conditions, a loyal customer may be deserves a break? I have no problem the customer deciding to pay or not, but if that is
stiffing or not is for the paperboy to decide IMO.

So, yes, you can certainly consider writing mocks for the PaperBoy, but I would not. Mocking is a tool I would use as the
last resort when unit testing.

How would I approach the above getPayment() method? Let's take a look:

public class Customer

   {

   public int getPayment(int amount) {

   if (hasNoMoney || doesNotCareToPay)

   return 0;

   else {

   deductMoney(amount);

   return amount;

   }

   }

   //...

Here the payment method does not depend on the PaperBoy. (If necessary you can pass information on what the payment is
for—paper, magazine, lawn moving, ...). The customer focuses on his/her own logic, whether to pay or not.

Now, how would the PaperBoy's collectPayment look like?

public class PaperBoy {

   public void collectPayments(List
      customers) {

      for(Customer customer : customers) {

      int payment = customer.getPayment(200);
if (payment == 0)

   if (payment > 0)

       acceptPayment(customer, payment);

      else

      stiff(customer);

      }

      }

      //...

Our paperboy thinks that if payment has not been received, he's been stiffed. He could change his view at anytime without
affecting the customer class. The paperboy is a bit more complex now, but that decision as to whether he's been stiffed or not
belongs to him, not the customer.

Now, how would we unit test the getPayment() method of the Customer. That's not a big deal. No mocking is needed. Simply
run your test on your customer instance.

If you think returning 0 for payment amount is not clear enough, you can return a Payment object with more details contained
in it like Cash, CreditCard, BrokeCantPay, DontFeelLikePaying, etc. as the type of payment. It can then include additional details
like credit card number, etc. or you can even extend the payment information object. That can be used for any payment, not just
payment for paper. The decoupling also makes the code more extensible.

So, when would I use a mock or a stub? I would first try to remove or reduce dependency as much as I can. After a serious effort
to do that, then for those dependencies that are still left I would do one of the following:

A. Separate the business logic in my code from the object it collaborates with. That way, I can run unit test on the logic. Depending
on the situation, I am quite content with integration testing the code that collaborate and unit test the code that does the important
logic. I do not think 100% of the code needs to be unit tested. I do think that 100% of the code should be exercised. So, if I can get
coverage of the code that does business logic through unit test and coverage of the code that collaborates, with the object it depends
on, through integration tests, I'm quite happy assuming it gives me a reasonable (not necessarily instantaneous) feedback loop.

B. If that separation is hard or if I think I need to really get a quick feedback on the code while testing the collaboration not just logic,
then and only then will I consider writing a mock. In short, I use mock as the last option when I do TDD. I will first try to knock it out.
Only if I really can't I will try to mock it out. First try to knockout before you consider to mock-out.

The tools and techniques for developing web applications on the .NET platform has come a long way. There was a time it was leading, then there was a time when it had to catch up. If you are developing web application on the .NET platform using Microsoft tools (as many developers do), I can't imagine today not relying on the MVC pattern and the capabilities of ASP.NET MVC Web Application Development framework.

The recently released "ASP.NET MVC In Action" from Manning by Jeffrey Palermo, Ben Scheirman, and Jimmy Bogard is a great way to deep dive into it.

The book is written for developers with practical knowledge of web development with ASP.NET. The authors get right into showing us how we will benefit from ASP.NET MVC and without wasting our time.

One of my favorites in the book is the emphasis on automated testing from the get-go.

The book does a good job of not only showing you what to do, but also provides cautionary words to avoid poor practices that may lead to maintenance issues on non-trivial applications. You'll learn how to organize and manage large applications, and also to what extent you can use your current ASP.NET skills and knowledge in ASP.NET MVC.

I feel that the discussion of MonoRail and Rails, taking one chapter, was a bit too much than I cared for. However, the authors do provide an objective comparison to ASP.NET MVC in the end of this chapter.

Overall, the book is a good read and well written. It certainly assumes you are familiar with web development and ASP.NET. If you have that background, it should be a breeze to get through the concept that will help you take good advantage of ASP.NET MVC.

Disclaimer: As I was reading the book, I was quite surprised to find that Ben had mentioned my name. Please do not hold it against him. :) It had no influence on my comments above.

I'm sure you've seen your share of long methods—methods that run several hundred lines.
Some of us may have even written them, probably in those days before we gained our
wisdom to write better quality code.

Long methods are evil on several grounds:

• They're hard to understand
• They're hard to change
• They're hard to reuse
• They're hard to test
• They have low cohesion
• They may have high coupling
• They ten to be overly complex

Often programmers ask, how "long" is a long method? A method is too long if

• you have to scroll down to look at the complete method
• it takes several minutes to understand
• you can't easily write an automated test for it
• you can't state the one prominent purpose for the method

One easy way to address long methods is to use the so called Compose Method Pattern.
Your methods then focuses on doing one thing and invokes other methods, all of which
are at the same level of abstraction. The result is shorter, easier to understand methods
in your application.

You say, "OK, I get it, but what about my colleague who has a compulsive disorder to
write very long methods, how do I convince that colleague?"

So you have tried to state the benefits, showed examples, and your colleague still does not get it.
OK, I can suggest one final drastic measure.

On a Monday morning, when you go to work, your colleague asks how your weekend was.
You could say, "It was good, I took the kids to the movie on Saturday and went to the park
on Sunday." That would be like using compose method pattern. You have stated your activities
at one level of abstraction. If your colleague is interested in more details about the movie or the
park, he or she can drill down into the details further asking you how the movie was, and so on.

But, do not reply to that question that way. Instead say, "Over the weekend I got into my car, started it,
drove 5 miles West, took a right turn, then a left turn, then drove another 10 miles, ..." Go at it for
several minutes until your colleague gets frustrated and interrupts you with "What's wrong with you."
Now simply reply, "oh, I though I'll tell you how my weekend way like you write your methods."