What are the possible problems with unit testing ASP.NET MVC code in the following way?

Question

I\'ve been looking at the way unit testing is done in the NuGetGallery. I observed that when controllers are tested, service classes are mocked. This makes sense to me becau

Answer 1

Even when you do not plan to mock an interface, I strongly suggest you to do not hide the real dependencies of an object by creating the objects inside the constructor, you are breaking the Single Responsibility principle and you are writing un-testable code.

The most important thing to consider when writing tests is: "There is no magic key to write tests". There are a lot of tools out there to help you write tests but the real effort should be put in writing testable code rather than trying to hack our existing code to write a test which usually ends up being an integration test instead of a unit-test.

Creating a new object inside a constructor is one of the first big signals that your code is not testable.

These links helped me a lot when I was making the transition to start writing tests and let me tell you that after you start, that will become a natural part of your daily work and you will love the benefits of writing tests I can not picture myself writing code without tests anymore

Clean code guide (used in Google): http://misko.hevery.com/code-reviewers-guide/

To get more information read the following:

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

and watch this video cast from Misko Hevery

http://www.youtube.com/watch?v=wEhu57pih5w&feature=player_embedded

Edited:

This article from Martin Fowler explain the difference between a Classical and a Mockist TDD approach

http://martinfowler.com/articles/mocksArentStubs.html

As a summary:

• Classic TDD approach: This implies to test everything you can without creating substitutes or doubles (mocks, stubs, dummies) with the exception of external services like web services or databases. The Classical testers use doubles for the external services only

  • Benefits: When you test you are actually testing the wiring logic of your application and the logic itself (not in isolation)
  • Cons: If an error occurs you will see potentially hundreds of tests failing and it will be hard to find the code responsible

• Mockist TDD approach: People following the Mockist approach will test in isolation all the code because they will create doubles for every dependency

  • Benefits: You are testing in isolation each part of your application. If an error occurs, you know exactly where it occurred because just a few tests will fail, ideally only one
  • Cons: Well you have to double all your dependencies which makes tests a little bit harder but you can use tools like AutoFixture to create doubles for the dependencies automatically

This is another great article about writing testable code

http://www.loosecouplings.com/2011/01/how-to-write-testable-code-overview.html