Your unit tests should be reasonably fine-grained. Typically, the fewer asserts, the more likely your test is to target a specific feature and not mix testing for multiple features in the same test. Does this mean that all tests should only have one assert? No, but I would consider it a "test smell" if I found several asserts, potentially testing multiple things in the same unit test. Treat this "smell" like you would a code smell and refactor the test to refine it so that it only tests one "thing" -- even if it requires more than one assert.
For example, I'm doing an MVC project now and one of the tests that I write is that the correct view is rendered by the action. There may actually be several of these if different code paths may result in different views. This is how I define it being the correct view: the result is the correct type and has the correct name. This requires two asserts, but I'm only testing one thing.
var result = controller.Action() as ViewResult;
Assert.IsNotNull( result );
Assert.AreEqual( viewName, result.ViewName );
I might do something similar with the model, but I would not test that the model is correct in the same test as checking the view because these are different aspects of the behavior of the code. I could change the expected model or view and by putting it in a separate test, only those tests concerned with that feature of the method need to be changed.
