Comments on: Unit Testing Simple ASP.NET MVC Controllers

By: Lakeview Personal Trainer

Lakeview Personal Trainer — Mon, 27 Feb 2012 08:12:00 +0000

Good news.This is a great post. I like this topic.This site has lots of advantage.
I found many interesting things from this site. It helps me many away.

By: MVC developr

MVC developr — Sat, 27 Nov 2010 11:24:47 +0000

Hey, i found this after some digging around
http://kbochevski.blogspot.com/2010/06/unit-testing-mvcnet.html
My colleagues found this very helpful too. It covers all the layers with unit testing and uses Rhino and MVC contrib, The source code is a good start for beginners like me

By: Klaus Hebsgaard

Klaus Hebsgaard — Mon, 15 Feb 2010 19:56:04 +0000

I have found that using the testdata builder pattern works great for controllers.
I would create the controller in a test data builder class, in a fluent like style, like:
var controller = new AdminControllerTestDataBuilder()
.WithSimpleFacilityrepository()
.WithMeetingRepository()
.withXYZ()
.Build();

And then I could insert instances where needed using :
WithFacilityrepository(facilityRepository.Object)

By: Sukant Hajra

Sukant Hajra — Wed, 10 Feb 2010 19:07:45 +0000

the way you’re doing Arrange-Act-Assert is pretty much the same as how I’ve been doing Given-When-Then in unit tests (without BDD-framework bloat)

By: Wes

Wes — Fri, 05 Feb 2010 21:13:13 +0000

This type of controller approach tends to work as a service layer in an application (when concerns are properly separated). In this case the controller is bringing together repositories and a user session which are components of the domain.

Mock based testing of service layers is often tedious and fragile as the tests duplicate the code in the service layer, any change to that code requires a change to the tests to make them pass. I constantly ran into this problem when mocking service layers or worse when I left domain logic in service layers.

Time has shown that focusing on invariants (state based testing), is the best way, at least for me, to do testing. In the case of a service layer, the invariants revolve around integrating components and as such testing should be from the integration perspective instead of a unit. If I find myself excessively mocking/stubbing in a service layer, it is often a smell that I have domain logic to extract (fat service calls). This helps maximize the testing surface of domain logic.

I usually work with a smoke test of the integration components to avoid duplicating the unit tests of the components it brings together. This allows the underlying component architecture to change, so long as the service still fulfills the same invariant.

In this example, a good smoke test for a controller action to add an item might be to check if it exists in the repository after the call. The repository would be stubbed instead of mocked, with an in memory version or a real database.

Another problem that frequently occurs with mock testing is the ignoring of argument values. These are important if our tests solely rely on the interaction of components instead of the invariants. In the example above, any Meeting object could have been added to the repository and the test would pass.

Just some thoughts on the pain points we’ve experienced with different testing strategies.

By: Jag Reehal

Jag Reehal — Fri, 05 Feb 2010 10:20:07 +0000

Hi Chris,

Yep behavior tests can be used for ASP.NET MVC Controllers and I especially like the AAA syntax :)

I did a similar post and covered other controller unit tests such as returning the correct view, and the Post-Redirect-Get pattern.

See http://www.arrangeactassert.com/how-to-unit-test-asp-net-mvc-controllers/