Now that I am getting more comfortable with MVC it is time to turn my attention to unit testing my controllers, (TDD I think it is called?).

I know, I should have been doing this all along but my brain can only handle learning 1 thing at a time now! .

Anyway, I have been looking at some tutorials that use things like MOQ but I am only currently using the standard VS Un it testing tools.

I have started with a very small unit test on controller that has only an Index() that captures a users browsers details as follows,

ViewData["UserAgent"] = Request.UserAgent;

Bad time to start looking into this, late on a very hot Friday afternoon, but this tripped up my first little tests when I realised that I didn't have the Request scope to use, Doh!

So, to save me a little head scratching I thought I would ask what the best methods and/or testing tools are to use to be able to test controllers that need Request/Form/Session variables. Obviously I need to mock this data somehow.

Can anyone suggest some good tutorials for someone with as tired brain as mine?

 Moq isn't a replacement for your unit testing suite (I use the MS tools as well), it's a mocking framework for doing exactly wha tyou're trying to do.  So...  get it, learn it, love it.  It'll make your life *tons* easier.

Second, it's really recommended that you don't use the 'environmentals' like Request in your controllers, but sometimes you have to, so...  Now, once you have Moq installed, you set a reference to it in your test project, and you can start using it to mock thigns like the Request.

Good tutorial here:

http://msbdusers.net/blogs/shahedkhan/archive/2009/05/15/10227.aspx

Scout7:

Now that I am getting more comfortable with MVC it is time to turn my attention to unit testing my controllers, (TDD I think it is called?).

Actually, TDD is a special form of unit testing.

Test Driven Development is part of one some people called agile development.

imo, agile development is a vulgar* use of "agile";.  See http://www.answers.com/agile.

   (*"vulgar" itself is a vulgar word; see http://www.answers.com/vulgar).

Simple example, unit testing versus TDD for the function squareThisNumber:

      (a) standard unit testing (test after testing):

                 (1)  I write my function:  int squareThisNumber(int n){return n*n};

                 (2)  I write a unit test to check that my function in (1) works.

      (b) test driven development testing (test before testing):

                  (1)  I write a unit test to check my unwritten function;
                         e.g.:  testMySquareFunction_2x2_is_4()
                                  {
                                      if (squareThisNumber(2) == 4) signalTestPassed;
                                   }

                  (2)  I write a "stub" for squareThisNumber so that my unit test will compile;
                         the stub might return 3 since 3 is not a square of any int.

                  (3)  I compile and run my test from (1); as expected it will fail.  Failure is often graphically signalled in red.

                  (4)  I now write my squareThisNumber function; if I get it right,
                         testMySquareFunction will pass.  Success is often graphically signalled in green.

The premise of TDD, also called "test first testing" is that because I write
my test before I write my function, I'll have give more thought to the design
of my function and therefore I'll craft better code.

Note:  depending to the complexity of the function I need, I may have to write many unit tests per function.

TDD is not agile except for someone who is very experienced with it.  A great programmer could write an entire system with zero unit tests (whether before or after).  Then, along comes Microsoft with .NET Framework 4.0 and something breaks the great programmer's working code.  Had the great programmer written unit tests, she/he would have discovered the new thank you Microsoft  bugs before sending off her/his work of art to unsuspecting end users.

See http://stephenwalther.com/blog/archive/2009/04/08/test-after-development-is-not-test-driven-development.aspx,
http://stephenwalther.com/blog/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx, and
http://martinfowler.com/articles/mocksArentStubs.html.

Regards,
Gerry (Lowry)

More refences:

http://www.codeplex.com/xunit  xUnit.net, authors Brad Wilson and Jim (James?) Newkirk

http://code.google.com/p/moq/  Daniel Cazzulino and Clarius Consulting

http://weblogs.asp.net/cazzu/archive/2008/04/22/moq-now-uses-xunit-for-its-unit-tests.aspx